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.
@boycottsystemd1 could you please perform at least several tests in a different time? Just to make sure an issue appears since 18.104.22.168 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 22.214.171.124, ie. works for me.
Could you pls check whether the previous version 2.53.8 has the same issue for you?
The version 126.96.36.199 introduces changes fro mail and news stuff mostly, so it should not differ in normal browser behaviour with 2.53.8 .
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 188.8.131.52 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).
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!
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.
@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...