Closed Bug 665138 Opened 13 years ago Closed 1 year ago

[10.7] Loading large pages slows UI to a crawl using latest Firefox trunk on OS X Lion

Categories

(Firefox :: General, defect)

5 Branch
x86
macOS
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: marcia, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: hang)

Attachments

(1 file)

Been seeing this for a few days using the latest trunk builds on 10.7.

STR:
1. Load https://crash-analysis.mozilla.com/crash_analysis/20110617/20110617_Firefox_4.0.1-interesting-modules-with-versions.txt.gz
2. Start beachballing.
3. Minefield must be force quit.

Apple report is attached.
Forgot to add I am using the latest Apple seed 11A494a.
Out of curiosity, try setting gfx.downloadable_fonts.enabled to false and see if this makes any difference.  This is one of the workarounds for bug 663688.
Loading this bug's page in a recent trunk nightly on Lion build 11A494a is (for me) painfully slow, and slows the UI to a crawl.  But it doesn't hang the browser.

For what it's worth, the same page also takes a horribly long time to load in Safari, and also slows its UI way down.  So this is presumably an OS bug.
I only see this on 10.7.
Summary: Hang when loading large pages using latest Firefox trunk → [10.7] Loading large pages slows UI to a crawl using latest Firefox trunk on OS X Lion
I turned the downloadable fonts pref to false and I still get the hang on that page using  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0a1) Gecko/20110617 Firefox/7.0a1.
viewing a 20MB .gz file of text data is going to bring just about any version of any browser to its knees.  Its a torcher test for sure.  If you let it run long enough I'm guessing it might recover.

I changed over the mime-type association on this new crash reporting server to allow direct viewing of .gz files in the browser, and its nice for viewing the smaller files without having to download, unzip, and then view locally; but the bigger files are more of a pain and will result in problems like this.

I guess you could just use wget to get the files.

Do we get the same kind of result when viewing the unzipped version of the file off the local harddrive?  That might be the interesting part of this bug if we see differences there, or with regression differences between versions of firefox or os versions.
I have actually loaded other large pages that weren't as big as https://crash-analysis.mozilla.com/crash_analysis/20110617/20110617_Firefox_4.0.1-interesting-modules-with-versions.txt.gz and seem some hanging issues on 10.7. I don't load that page every day, but on other occasions I have seen the latest trunk hang on pages. So I definitely think there may be some issues here, but I will have to explore further.
My (subjective) feeling is that the effects of loading this bug's page (into either Firefox or Safari) are way worse on 10.7 than they are on 10.6.  But I only loaded it three times altogether (and only once on 10.6).
When I save the file to my hard drive, unzip it and then open in the browser, I get the same hang.

Note on the same machine when I open it in Chrome from https that does not happen.
Interestingly, I can now get a current nightly to "hang" pretty reliably (testing on OS X 10.6.8), if I try to scroll https://crash-analysis.mozilla.com/crash_analysis/20110617/20110617_Firefox_4.0.1-interesting-modules-with-versions.txt.gz while it's loading.  Particularly (I think) if I let the mouse go outside the browser window (over the desktop).

It does eventually come out of the "hang", but that can take several minutes -- this on a brand new MacBook Pro.

As I have time over the next week or so, I'll try to see what patterns I can find in the stacks I get while "hanging" (in an opt build with debug symbols, of course).
Severity: normal → S3

Unable to reproduce and 10.7 is no longer supported.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: