Created attachment 214937 [details] Rendering duckduckgo.com Current firefox package (77.0) from latest repos fail to render most pages. In attachment example of rendering duckduckgo. Firefox 76 render this page just fine.
Not enough details. firefox-77.0,1 (rc1) works fine on 12.1 amd64 and firefox-77.0_1,1 (rc2) works fine on 11.3 i386. Both X11 and Wayland.
Created attachment 214956 [details] Save page as from https://duckduckgo.com/?kp=-1 Looking at that with od -a, the repeated ef bf bd pattern suggests an utf-32 encoding.
I see the same issue with firefox-77.0_1,1 on 12.1-STABLE r361383 amd64. Starting firefox with --safe-mode make no difference. Apparently, only the displayed page is corrupted ; view-source:<URL> looks right.
I am seeing this issue with 12.1-RELEASE-p5 and X11. Firefox-77.0_3,1. By changing network.http.accept-encoding.secure to null in about:config, the issue is resolved (i imagine network.http.accept-encoding also must be changed but I haven't tried.) I don't think disabling encoding is a long-term solution, and hope the issue can be resolved asap..
Removing everything from accept-encoding did indeed greatly improve the situation, going from most pages don't render to almost everything is fine, and made the browser usable again, but there are still a few urls that show only garbage, for instance https://usn.ubuntu.com/.
(In reply to megamansec from comment #4) Is there any proxy or other middle box between you and the internet? (can you test with a local server?) With this "fix" the problem sounds suspicously like "something in between" (I cannot reproduce the problem here, neither with FreeBSD's firefox nor with stock firefox on linux).
(In reply to Christoph Moench-Tegeder from comment #6) Thank you for the reply. I cannot test with a local server right now, but perhaps this is worth noting: Looking at https://usn.ubuntu.com/ (note I am only using usn.ubuntu.com as an example) firefox: garbage chrome: no problem curl: garbage. curl --compressed: no problem. The only different between curl --compressed and non is: bad: accept: */* good: accept-encoding: deflate, gzip I have provded a traceroute of usn.ubuntu.com. DD-WRT is my router which I have made no recent changes to, and the second hop is something controlled by my ISP. I do not think the issue lies with this though, considering I am using TSL to connect with usn.ubuntu.com.
Created attachment 215177 [details] Traceroute
(In reply to megamansec from comment #7) Let's stick to usn.ubuntu.com for a moment. That server sends compressed data by default, but marks that with "Content-Encoding: gzip", which looks correct (here, firefox picks that up and... just works). Firefox sending Accept-Encoding, getting compressed content (with Content-Encoding) and displaying that is even more correct. (Are those headers intact in your case?). Having to clear out Accept-Encoding is an ugly hack. Curl only tries to decompress content if it has been told to request compression, which sometimes makes debugging harder than it should be.
Huh, I didn't know that about curl. Anyways, see https://i.imgur.com/Ri8Wt4S.png for headers.
In comment #3, I wrote: Starting firefox with --safe-mode make no difference. Starting with a clean default configuration (by moving $HOME/.mozilla away), on the other hand, works. Maybe there is a setting, or a combination of settings, uncommon but not entirely extravagant (there are at least 3 of us having the issue), that was fine up to version 76 but is not any longer.
Headers look totally normal. But then - did you ever touch any of the HTTP/2- or spdy-related settings? (the easier way to find out would be diffing prefs.js, I think)
Created attachment 215238 [details] prefs.js file
The setting that creates the problem is apparently user_pref("browser.tabs.remote.autostart", false); If I set that to true (the default) in my profile, everything is fine. If I set it to false in a clean profile, it is enough to recreate the issue. It is set to false in the prefs file attached by megamansec as well. I tried the same test on an Ubuntu 20.04 machine since firefox 77 just appeared on it and couldn't reproduce the problem there.
(In reply to Philippe Michel from comment #14) > I tried the same test on an Ubuntu 20.04 machine since firefox 77 > just appeared on it and couldn't reproduce the problem there. Ubuntu defines MOZILLA_OFFICIAL for telemetry[1] which disables[2] the e10s pref. Prepending "env MOZ_FORCE_DISABLE_E10S=1" should still work. Not a supported configuration upstream. Both fiddling with random prefs in about:config and disabling multi-process support since Firefox 68. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1352981#c5 https://searchfox.org/mozilla-central/rev/baf1cd492406/toolkit/moz.configure#663 https://salsa.debian.org/mozilla-team/firefox/-/blob/543a3517e00ccf/debian/rules#L41 [2] https://searchfox.org/mozilla-central/rev/baf1cd492406/toolkit/xre/nsAppRunner.cpp#5020
Fixed upstream since Firefox 78. Noticed while reading https://groups.google.com/d/topic/mozilla.dev.platform/GTzbsV6eztc/discussion