Loading a certain page makes FF unresponsive

NEW
Unassigned

Status

()

Core
DOM
P3
normal
a year ago
a year ago

People

(Reporter: simon.thum, Unassigned, NeedInfo)

Tracking

45 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160905130425

Steps to reproduce:

Open

http://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

done.


Actual results:

After about 20 secs of loading (50 mbit), FF needed to be killed.

On restart I could close the site early without fuss. No other problems were observed.


Expected results:

It should have continued loading this page until it completes, but allowing me to kill the tab without killing the whole browser all the time.

However, it is probably acceptable to deny or pause loading the whole page under such circumstances.

Comment 1

a year ago
For the records, the raw HTML of that page is 354MB...
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20161025030205

I have tested this issue on Firefox 45.0 (Build ID: 20160905130425 ) and managed to reproduce it. Firefox becomes unresponsive after 25 seconds of loading.
I also tested with the latest Firefox release (49.0.1) and latest Nightly (Build ID: 20161025030205 ) and Firefox crashes after being unresponsive.

Crash signatures:
 
https://crash-stats.mozilla.com/report/index/535c4d85-9cdb-4c77-8b6d-4ef922161026 -  FF latest Nightly
https://crash-stats.mozilla.com/report/index/000208a7-15d5-4748-ad75-61c1a2161026 -  FF release 49.0.1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → General
I think the "expected results" devolve to "enable e10s", which we are already doing on release - but you're running 45 (maybe ESR, maybe because you're on a "stable" distro?) so that doesn't happen.

I don't know if layout or DOM or the parser code could abort based on some dynamic limit connected to your system's memory state. Clearly constructing a DOM based on 400mb of HTML is going to go badly on a lot of machines. Either way, this is a Core issue.
Component: General → Untriaged
Product: Firefox → Core
Component: Untriaged → DOM
I'm interested how other browsers perform with this page. If it's better in Chrome, can you get a profile and upload it? https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Flags: needinfo?(simon.thum)
Priority: -- → P3
(Reporter)

Comment 5

a year ago
Hi,

chrome keeps up pretty well, it did not get unresponsive or crash. I don't know what "e10s" is but I suspect it's of little value when I profile on my (supposedly non-standard) gentoo build. Maybe this issue should be postponed until it is clear if e10s will fix it?
Flags: needinfo?(simon.thum)
e10s is short-hand for Electrolyis (https://wiki.mozilla.org/Electrolysis) which is Mozilla's effort to run web content in its own OS process, separate from the rest of the browser UI.

Simon, any chance you can reproduce with a Mozilla-issued build and get a profile? It'll help to know if it's the Gentoo build flags or if it's something else. Something like http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-52.0a1.en-US.linux-x86_64.tar.bz2 would be great. You can start the extracted build with the profile manager to get a clean profile with -P: ./firefox -P -no-remote (that'll prevent it from trying to re-use an existing Firefox process's window).

Thanks!
Flags: needinfo?(simon.thum)
You need to log in before you can comment on or make changes to this bug.