Bug 225233 - www/firefox 58.0 hangs on some requests
Summary: www/firefox 58.0 hangs on some requests
Status: Closed Feedback Timeout
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: 2018-01-16 21:25 UTC by aryeh.friedman
Modified: 2018-10-30 23:46 UTC (History)
2 users (show)

See Also:


Attachments
Preamble: a screenshot of Surf around three minutes before this morning's incident (75.50 KB, image/png)
2018-07-15 13:00 UTC, Graham Perrin
no flags Details
Preamble: the safe mode instance of Firefox that was used to create then launch the new profile (68.90 KB, image/png)
2018-07-15 13:01 UTC, Graham Perrin
no flags Details
Welcome to Firefox – not loading (273.86 KB, image/png)
2018-07-15 13:02 UTC, Graham Perrin
no flags Details
Firefox Privacy Notice — Mozilla – not loading (25.06 KB, image/png)
2018-07-15 13:04 UTC, Graham Perrin
no flags Details
third tab – loaded (339.25 KB, image/png)
2018-07-15 13:06 UTC, Graham Perrin
no flags Details
Side note: a subsequent workaround, for a different issue, in the first instance of Firefox (446.41 KB, image/png)
2018-07-15 13:12 UTC, Graham Perrin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description aryeh.friedman 2018-01-16 21:25:27 UTC
When attempting to open an arbitary URL (gmail or a local file for example but any other URL also has same issue) in some cases the browser will hang and not load the tab.   By hang I mean the tab goes into an infinite loading state.  While the tab is in hang state all other tabs will refuse to (re)load.

This is an intermittent issue but happens about 10% of the time.
Comment 1 Jan Beich freebsd_committer freebsd_triage 2018-01-17 00:55:18 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
Comment 2 aryeh.friedman 2018-01-18 06:31:57 UTC
(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??)
Comment 3 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 12:55:45 UTC
(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
Comment 4 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:00:13 UTC
Created attachment 195141 [details]
Preamble: a screenshot of Surf around three minutes before this morning's incident
Comment 5 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:01:37 UTC
Created attachment 195142 [details]
Preamble: the safe mode instance of Firefox that was used to create then launch the new profile
Comment 6 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:02:39 UTC
Created attachment 195143 [details]
Welcome to Firefox – not loading

2018-07-15 09:21:58
Comment 7 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:04:27 UTC
Created attachment 195144 [details]
Firefox Privacy Notice — Mozilla – not loading

2018-07-15 09:22:10

<https://www.mozilla.org/en-US/privacy/firefox/>
Comment 8 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:06:54 UTC
Created attachment 195145 [details]
third tab – loaded

2018-07-15 09:22:46

<https://blog.waterfoxproject.org>
Comment 9 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:12:52 UTC
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.
Comment 10 Graham Perrin freebsd_committer freebsd_triage 2018-07-15 13:50:08 UTC
(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 …
Comment 11 Jan Beich freebsd_committer freebsd_triage 2018-08-14 12:46:55 UTC
Probably https://bugzilla.mozilla.org/show_bug.cgi?id=1476130
Comment 12 Graham Perrin freebsd_committer freebsd_triage 2018-08-17 20:49:05 UTC
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.
Comment 13 commit-hook freebsd_committer freebsd_triage 2018-09-26 16:06:03 UTC
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
Comment 14 commit-hook freebsd_committer freebsd_triage 2018-09-26 16:07:07 UTC
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
Comment 15 Graham Perrin freebsd_committer freebsd_triage 2018-10-30 23:46:43 UTC
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