Bug 225233
| Summary: | www/firefox 58.0 hangs on some requests | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | aryeh.friedman |
| Component: | Individual Port(s) | Assignee: | freebsd-gecko (Nobody) <gecko> |
| Status: | Closed Feedback Timeout | ||
| Severity: | Affects Only Me | CC: | grahamperrin, jbeich |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| Attachments: | |||
|
Description
aryeh.friedman
2018-01-16 21:25:27 UTC
What FreeBSD version? I can't reproduce. Let's wait for "me too" replies to narrow down the cause. - Try on a new profile: Run as "firefox -new-instance -profile $(mktemp -d)" - Try using a SOCKS v5 proxy e.g., via security/tor; proxy DNS as well - Try with multi-process disabled: open about:config, browser.tabs.remote.autostart -> false, restart browser - Try with Stylo disabled: open about:config, layout.css.servo.enabled -> false, restart browser - Try applying the patch in bug 222356 - Try attaching gdb/lldb and dumping stacktrace of the processes consuming 100% CPU - Try running firefox via ktrace -i if CPU usage is low during hangs (In reply to Jan Beich from comment #1) Remaking my profile seems to have solved the hangs but has created an other problem of some web apps refuse my login attempts (works on 57.X and chromimum on the same machine). One of the web apps I know nothing has changed since the browser upgrade since I am the developer of it. The refused login is cleared by restarting the browser and seems to be related to if I have logged in during the browser session to the same app (not killing session cookies??) (In reply to aryeh.friedman from comment #0) > … an intermittent issue but happens about 10% of the time. Maybe less than five percent in my case. It's amongst the issues that cause me to hesitate before switching (from Waterfox) to Firefox. First noticed months ago. I have a vague recollection that it began at or around the time of Firefox Quantum; 57. If the issue had been noticeable with Firefox 56.0.2 or less, I'd almost certainly have a clearer memory of it. NB all my production (non-test) uses of 56.0.2 and less had e10s disabled, which makes me wonder … … whether this bug 225233 will be reproducible only with e10s enabled. ---- In the most recent incident, this morning, I used a first instance of Firefox, in safe mode, to create a new profile, then launch the new profile in a new browser in normal mode. Result: - neither of the initial tabs (welcome, privacy notice) loaded - the third tab (a pasted URL) did load, without difficulty. To follow: - screenshots - the profile, and the cache directory. When there's nothing more than a spinning asynchronous progress indicator: - I know (from experience) to not bother with a reload - I'll get the content to load only if I copy the address, then go there in a new tab. ---- $ pkg info firefox | grep Version Version : 61.0.1_1,1 $ date ; uname -v Sun 15 Jul 2018 13:35:22 BST FreeBSD 12.0-CURRENT #7 r336136: Tue Jul 10 03:01:24 BST 2018 root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Created attachment 195141 [details]
Preamble: a screenshot of Surf around three minutes before this morning's incident
Created attachment 195142 [details]
Preamble: the safe mode instance of Firefox that was used to create then launch the new profile
Created attachment 195143 [details]
Welcome to Firefox – not loading
2018-07-15 09:21:58
Created attachment 195144 [details] Firefox Privacy Notice — Mozilla – not loading 2018-07-15 09:22:10 <https://www.mozilla.org/en-US/privacy/firefox/> Created attachment 195145 [details] third tab – loaded 2018-07-15 09:22:46 <https://blog.waterfoxproject.org> Created attachment 195146 [details] Side note: a subsequent workaround, for a different issue, in the first instance of Firefox 2018-07-15 09:25:17 Back to the first instance of Firefox, a workaround for a different issue. Where previously (09:19:42) the page <https://blog.waterfoxproject.org/> was blank _without_ an asynchronous progress indicator, now there is content. Worked around by clearance of cookies and site data, IIRC followed by a simple reload. (In reply to comment #3) > - the profile, and the cache directory. Sorry, I'm having trouble attaching the profile. An archive of the root directory is not too large (4.0 MiB), cj0w18v3.new.tar.gz I get: > 400 Bad Request > > nginx An archive of the local directory (cache) will be too large (11.5 MiB), cache-directory-cj0w18v3.new.tar.gz ---- Is either file required? If so, I can use Firefox Send … Thanks. At the time of writing – Firefox 61.0.2,1 on r337679 – I can not reproduce the issue. I'll update to r337986 then retest. A commit references this bug: Author: jbeich Date: Wed Sep 26 16:05:49 UTC 2018 New revision: 480744 URL: https://svnweb.freebsd.org/changeset/ports/480744 Log: www/firefox: document e10s instability PR: 225233 228855 Changes: head/www/firefox/pkg-message head/www/firefox-esr/pkg-message head/www/waterfox/pkg-message A commit references this bug: Author: jbeich Date: Wed Sep 26 16:06:50 UTC 2018 New revision: 480745 URL: https://svnweb.freebsd.org/changeset/ports/480745 Log: MFH: r480744 www/firefox: document e10s instability PR: 225233 228855 Approved by: ports-secteam blanket Changes: _U branches/2018Q3/ branches/2018Q3/www/firefox/pkg-message branches/2018Q3/www/firefox-esr/pkg-message branches/2018Q3/www/waterfox/pkg-message This evening with 63.0_3,1 I had what I first thought might have been a recurrence of symptoms of this bug. On closer inspection: - blankness, with _no_ asynchronous progress indicator. Screen recorded. ---- A long shot … I asked a question under (not a bug) - bug 228314 - www/firefox Some web sites display blank page |
