Bug 246790 - www/firefox 77.0 fail to render most pages
Summary: www/firefox 77.0 fail to render most pages
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-gecko (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-27 22:10 UTC by sasamotikomi
Modified: 2020-06-28 09:44 UTC (History)
3 users (show)

See Also:
jbeich: maintainer-feedback+


Attachments
Rendering duckduckgo.com (47.67 KB, image/png)
2020-05-27 22:10 UTC, sasamotikomi
no flags Details
Save page as from https://duckduckgo.com/?kp=-1 (3.33 KB, text/plain)
2020-05-28 08:27 UTC, Philippe Michel
no flags Details
Traceroute (1.28 KB, text/plain)
2020-06-02 18:56 UTC, megamansec
no flags Details
prefs.js file (28.35 KB, application/x-javascript)
2020-06-04 21:23 UTC, megamansec
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasamotikomi 2020-05-27 22:10:56 UTC
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.
Comment 1 Jan Beich freebsd_committer 2020-05-28 06:43:52 UTC
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.
Comment 2 Philippe Michel 2020-05-28 08:27:44 UTC
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.
Comment 3 Philippe Michel 2020-05-28 08:29:04 UTC
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.
Comment 4 megamansec 2020-06-01 17:28:15 UTC
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..
Comment 5 Philippe Michel 2020-06-02 17:28:07 UTC
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/.
Comment 6 Christoph Moench-Tegeder freebsd_committer 2020-06-02 18:11:06 UTC
(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).
Comment 7 megamansec 2020-06-02 18:56:24 UTC
(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.
Comment 8 megamansec 2020-06-02 18:56:59 UTC
Created attachment 215177 [details]
Traceroute
Comment 9 Christoph Moench-Tegeder freebsd_committer 2020-06-02 21:16:55 UTC
(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.
Comment 10 megamansec 2020-06-02 21:30:21 UTC
Huh, I didn't know that about curl.
Anyways, see https://i.imgur.com/Ri8Wt4S.png for headers.
Comment 11 Philippe Michel 2020-06-04 18:50:14 UTC
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.
Comment 12 Christoph Moench-Tegeder freebsd_committer 2020-06-04 21:07:07 UTC
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)
Comment 13 megamansec 2020-06-04 21:23:31 UTC
Created attachment 215238 [details]
prefs.js file
Comment 14 Philippe Michel 2020-06-06 09:16:04 UTC
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.
Comment 15 Jan Beich freebsd_committer 2020-06-06 14:54:39 UTC
(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
Comment 16 Jan Beich freebsd_committer 2020-06-28 09:44:23 UTC
Fixed upstream since Firefox 78. Noticed while reading
https://groups.google.com/d/topic/mozilla.dev.platform/GTzbsV6eztc/discussion