Comments
buc
It seems that sizes of rpm packages for epel7 is much larger than on Fedora branches.
Unstripped binaries? If so, why?
Fe., latest Firefox takes 275Mb on el7, whereas chromium + chromuim-comon take about 1.3Gb 8)
This update has been unpushed.
You need the latest libjxl-0.6.1 from F35's updates-testing.
@boycottsystemd1 could you please perform at least several tests in a different time? Just to make sure an issue appears since 2.53.8.1 exactly.
Sometimes there are strange failures at attempt to login to the bodhi site, but this does not apply to any particular SM version. Recently it was happen to me with 2.49.5 .
@boycottsystemd1 just writing here by logging with 2.53.8.1, ie. works for me.
Could you pls check whether the previous version 2.53.8 has the same issue for you?
The version 2.53.8.1 introduces changes fro mail and news stuff mostly, so it should not differ in normal browser behaviour with 2.53.8 .
no issues
Well, I found two bugs and ship 2.53.7-3 which fixes both. The same time I reported it upstream. After a while, upstream ships 2.53.7.1 with the same fixes. So this is the classic chicken and egg dilemma. :)
Regarding User-Agent string, we do not mention SM in it at all. Unfortunately, the modern World is confised a lot by the menition of something "untypical" in this string. So, "Identify as Firefox" by default. (Fe. go to google.com and see how it changes when you start to mention SM. Some banking sites just drop you, and so on).
@lam, it looks like upstream bug 1702903 (will be fixed in upcoming release soon).
To fast check without recompiling, you can try to apply changes from https://bugzilla.mozilla.org/show_bug.cgi?id=1702903#c4 against omni.ja:modules/commonjs/sdk/ (it is zip archive actually).
This update has been unpushed.
The needed patches from upstream 2.53.5.1 are already backported in 2.53.5-2
Gtk-based menu loads icons using gdk-pixbuf2 (which uses a specific handler for each image type). To understand what format the image is, a small amount of bytes at the head of the file is read (similar to file(1) command).
Certainly if the key fragment "<svg" are present at offset more than 256 bytes (200 + the first <?xml...> string), it is unlikely that anybody will read the whole file then just to understand its format.
BTW, if we put "<svg>" inside the comment (but somewhere in [0, 256]), it fixes the issue too... :)
Thanks for report and help!
KDE4 seems unaffected (under CentOS-7).
Probably some gtk2/gtk3 issue.
I've also tested that el7's Mate affected, and even el6-'s Gnome2 affected too (besides F33).
Could you check KDE and/or Gnome3?
sunwire,
Could you please test a new variant of the svg icon: https://bugzilla.mozilla.org/attachment.cgi?id=9187809 ? Ie. place it as /usr/share/icons/hicolor/scalable/apps/seamonkey.svg
Well, capable to reproduce it.
Seems MATE allows only one one-line comment before <svg>...</svg> block.
Fortunately it allows several comments, and even a multiline comment just after the initial <svg ...... >
I'll try to fix it properly in the nearest time.
A similar seamonkey-mail.svg seems OK. The difference is that seamonkey.svg has several comments, and some of the comments are multiline.
Could you please test with various comments variants? Ie. unite all into one big comment, try to leave only one line (as in seamonkey-mail.svg) etc.etc.etc.
Kinda magic here! :)
Actually, the final tarball was ready at 7 Sep. Due to bureaucratic problems and lack of man power, it is still going to archive.mozilla.org. (Now it has made a halt in http://archive.mozilla.org/pub/seamonkey/tmp/releases/2.53.4/ :) )
Being a bit involved into upstream, I was able to get the tarball a bit earlier. Surely it has the same checksums etc.
Yep, it seems fixed in Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1409158 I'll try to backport it in the next release.
@notandor: Seems to be even more easy -- try to preserve "intl.locale.matchOS" as default (ie. true), and just run SeaMonkey with LC_MESSAGES=C (and probabaly LC_TIME=C). Actually en_US wiil be used for UI, but no am/pm for times...
Glad to hear. BTW it is the first update comment for epel8 branch at all. Now I know that SeaMonkey users exist in CentOS 8 world! :)
Could you at least roughly give some examples of sites (or pages within sites) that have experienced this improvement? Initially, it was done for www.bing.com . It could be interesting which other sites affected in order to more thoroughly investigate the issue on a larger set of different reproducible cases.