Open Bug 1123039 Opened 7 years ago Updated 4 years ago

long pages (not necesarily lots of text) cause firefox to hang real bad and sometimes crash especialy on mxr and dxr

Categories

(Core :: Disability Access APIs, defect)

36 Branch
x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

REOPENED

People

(Reporter: noitidart, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [testday-20150123])

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150114125146

Steps to reproduce:

i use mxr a lot and some times a page has lots of text and it causes firefox to hang real bad and other times to crash.

i also witnessed this issue on reacotros svn: http://doxygen.reactos.org/files.html
i didnt report this till now because i thought it was just me, but another of my friends reports the same issue but on dxr
Do you have crash reports (bp-...) related to this issue in about:crashes?
i don't know how to identify them.
its rare i get a crash report because firefox just hangs and hangs and hanges and i eventaully have to ctrl + alt + del.

next time i wont ctrl alt del it. i have waited 10 minutes in past
On my side, Firefox freezes during 2 or 3 sec (but still responding) but doesn't crash and is able to load the webpage.
Could you test in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) then with a fresh profile (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles).
Everything's fine for me on http://doxygen.reactos.org/files.html on 36b1, 38.0a1 (2015-01-19) Win 7
Flags: needinfo?(noitidart)
(In reply to Paul Silaghi, QA [:pauly] from comment #5)
> Everything's fine for me on http://doxygen.reactos.org/files.html on 36b1,
> 38.0a1 (2015-01-19) Win 7

Hey all I tried with fresh profile it was much faster, only froze for a second.
I tried in safe mode of that new profile too: this one froze for 3 seconds.


Here are other pages that cause big time lags:
http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/build/pdf.worker.js#1136

This page does even my brand new profile in. Its been 30 seconds still hasnt un-hung.

There was a dxr page that hung for like 10sec too Ill post that soon ill look around for it.
Flags: needinfo?(noitidart)
Its been however much time since i last posted, that mxr page still has my clean profile hanging.


Here's the dxr page that locks up for 6 seconds: http://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2527

on clean profile
that mxr page in my new profile, unhung sometime in the last 3 minutes (i last checked 3 min ago and it was hung) so that was at least 8 minutes of hanging)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

I cannot reproduce, no locks or hangs for my with the above site
Whiteboard: [testday-20150123]
Oh guys enable smooth scroll i think thats what does it! Like a page finally loaded then i tried scrolling and it locked up again. When i disabled smooth scroll i could at least scroll. Reloading the page took long time though.

Page was: http://mxr.mozilla.org/mozilla-release/source/content/base/src/nsContentUtils.cpp#186
> Page was: http://mxr.mozilla.org/mozilla-release/source/content/base/src/nsContentUtils.cpp#186
This file does not exist at this moment...

The rest of your links work fine for me on the current Nightly, and sounds like no-one else here sees the problem.

Can you come up with steps to reproduce using a clean profile, that someone else (your friend?) can reproduce? Try to reproduce on a Nightly and on a different system.

Also, perhaps these will help:
https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Flags: needinfo?(noitidart)
(In reply to Nickolay_Ponomarev from comment #11)
> > Page was: http://mxr.mozilla.org/mozilla-release/source/content/base/src/nsContentUtils.cpp#186
> This file does not exist at this moment...
> 
> The rest of your links work fine for me on the current Nightly, and sounds
> like no-one else here sees the problem.
> 
> Can you come up with steps to reproduce using a clean profile, that someone
> else (your friend?) can reproduce? Try to reproduce on a Nightly and on a
> different system.
> 
> Also, perhaps these will help:
> https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler

Hey Nickolay i finally found out a way to reproduce this. Please go to dxr.mozilla.org and type in vtable it will have super heavy usage and/or crash.

I think its trying to load this page: https://dxr.mozilla.org/mozilla-central/source/db/sqlite3/src/sqlite3.c?from=vtable#11491
Flags: needinfo?(noitidart)
oh correction it didnt crash but it hung forever, so i had to ctrl+alt+del and force quit due it not crashing
I didn't managed to reproduce this on the latest release(43.0.2) nor the latest Nightly(46.0a1).

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151221130713

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160103030302

I have tried to open this page https://dxr.mozilla.org/mozilla-central/source/db/sqlite3/src/sqlite3.c?from=vtable#11491 in Firefox, Nightly, Chrome and IE 11, but the page is no longer available.

Although, I have tried the scenario that you described in Comment 12: `Hey Nickolay i finally found out a way to reproduce this. Please go to dxr.mozilla.org and type in vtable it will have super heavy usage and/or crash.`, the page is properly loaded and no issues were found.

Can you please try to reproduce this on the latest release(43.0.2) and latest Nightly(46.0a1) and provide the results?
When doing this, you could create a new clean Firefox profile, or maybe test in safe mode, as some of this issues may be caused by third party installed addons or custom settings
(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thank you,
Vlad
Flags: needinfo?(noitidart)
Hi,

Considering the fact that the reporter did not provide more information on my request and the issue can't be reproduced, I will mark this issue as Resolved - WFM. 
If you can still reproduce this, feel free to reopen it and provide the requested information.

Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(noitidart)
Resolution: --- → WORKSFORME
Firefox 44.0.1 when going to http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/build/pdf.worker.js#1136 on Win 7 x64 (x86 browser) hangs up for a good 30 seconds with an AppHangB1 for me. So this is still reproducible.

New profile used, all default settings, no extensions.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
(In reply to Mark Straver from comment #16)
> Firefox 44.0.1 when going to
> http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/
> build/pdf.worker.js#1136 on Win 7 x64 (x86 browser) hangs up for a good 30
> seconds with an AppHangB1 for me. So this is still reproducible.
> 
> New profile used, all default settings, no extensions.

Hey Mark,

Do you think you'd be able to get us a performance profile? Instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Flags: needinfo?(mark)
Using the profiler extension made things 50x worse. I had to wait 20 minutes (!!) for it to unfreeze.

https://cleopatra.io/#report=6c15cf80467490e9548faee6509cdd0869752abd&selection=0,1,2,3,3,4
Flags: needinfo?(mark)
An absolutely humongous amount of time is being spent inside our accessibility layer.

Do you have a screen reader attached? Or are you using RDP to connect to the machine running Firefox?
Flags: needinfo?(mark)
No, I don't have a screen reader and am not using RDP, but I think I pinpointed the problematic program being a productivity tool that adds window functions to running programs. Disabling the application prevented the huge hangup. Without it, the pause is reduced to an acceptable 3-4 seconds, most of which is spent in PresShell::Flush (Flush_Style) and the same for (Flush_InterruptibleLayout).

I'll contact the devs of the productivity tool to see if they can come up with a better solution, in the meanwhile -- there's clearly a big issue with interoperability here.
Flags: needinfo?(mark)
Also, apologies for half-hijacking this bug, as it turned out to be something completely different than a scrolling hang.
Hi,

I have tried to reproduce this issue on latest release(44.0.2) and the latest Nightly(47.0a1) on Windows 8.1 and Windows 7 using the link provided in Comment 16. I have tested the x32 and x64 browser builds.

While testing I have observed two behaviours:
#1 - Using the latest release (44.0.2), the browser hangs for ~1-2 seconds (sometimes it doesn't hang at all) before the jump from the current line to the line specified in the URL is made. there is a lot of data to be loaded and this happens for me also on Chrome v48.0.
#2 - Using the latest Nightly(47.0a1), the browser doesn't hang at all.

From my point of view the browser doesn't hang real bad and it doesn't crash.

Do you think it's safe to close this issue as Resolved-WFM, based on Comment 20 and Comment 21?
Do you consider the productivity tool caused the issue rather than the browser?

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160211075650

Thank you,
Vlad
Flags: needinfo?(mconley)
Flags: needinfo?(mark)
Vlad, the productivity tool (actual window manager) is actually a known bad player for Firefox, since it also interfered with e10s due to triggering of a11y. It doesn't cause the issue in and of itself, because I can unload the tool and Firefox will still hang up badly as indicated unless it is completely exited and restarted without the tool loaded. I haven't tried on nightly yet, will do that later and report back.
Flags: needinfo?(mark)
Clearing needinfo, as we're waiting on Mark to report back.
Flags: needinfo?(mconley)
Sorry for not reporting back sooner.
I tried nightly, which informed me that a11y was "partially disabled" on startup, and it didn't display the issue, although there was still a pretty bad pause of 10 seconds or so.
Cleopatra for that run:
https://cleopatra.io/#report=cd595a42391ffac6e5115e9acfeb170767e9358b

After the first run, exiting (which I had to do through task manager since Firefox refused to close down) and restarting to verify, it no longer gave the accessibility message, but the problem was back in full force. I didn't want to wait another 20 minutes ;)
It's been the same since.
Extremely long lengths of time are still being spent in mozilla::a11y::NotificationController::WillRefresh.

Mark, in attempt to confirm that our a11y APIs are being used (and maybe abused) here, can you please try setting accessibility.force_disabled to 2 in about:config, and attempt to reproduce again?

If the issue goes away there, then I'll forward this along to our a11y team to investigate.
Flags: needinfo?(mark)
Loaded nightly, first verified the problem persisted -- it did.
Set accessibility.force_disabled to 2, problem went away.
Flags: needinfo?(mark)
Okay, so it sounds like some third-party piece of software is using our accessibility APIs here, and those APIs are running really hot.

Hey tbsaunde, do you know if our accessibility APIs are _expected_ to run really hot on pages like http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/build/pdf.worker.js#1136 ?
Flags: needinfo?(tbsaunde+mozbugs)
> Hey tbsaunde, do you know if our accessibility APIs are _expected_ to run
> really hot on pages like
> http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/
> build/pdf.worker.js#1136 ?

it would of course be a bug.  That said I'm not sure I can reproduce it being slow.
Flags: needinfo?(tbsaunde+mozbugs)
(In reply to Trevor Saunders (:tbsaunde) from comment #29)
> > Hey tbsaunde, do you know if our accessibility APIs are _expected_ to run
> > really hot on pages like
> > http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/
> > build/pdf.worker.js#1136 ?
> 
> it would of course be a bug.  That said I'm not sure I can reproduce it
> being slow.

Fair enough. I've moved this bug into Firefox :: Disability Access. Is that the right place? Is there anything else I need to do to get this bug triaged?
Component: Untriaged → Disability Access
Flags: needinfo?(tbsaunde+mozbugs)
Component: Disability Access → Disability Access APIs
Flags: needinfo?(tbsaunde+mozbugs)
Product: Firefox → Core
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #30)
> (In reply to Trevor Saunders (:tbsaunde) from comment #29)
> > > Hey tbsaunde, do you know if our accessibility APIs are _expected_ to run
> > > really hot on pages like
> > > http://mxr.mozilla.org/mozilla-beta/source/browser/extensions/pdfjs/content/
> > > build/pdf.worker.js#1136 ?
> > 
> > it would of course be a bug.  That said I'm not sure I can reproduce it
> > being slow.
> 
> Fair enough. I've moved this bug into Firefox :: Disability Access. Is that
> the right place? Is there anything else I need to do to get this bug triaged?

core::disability access API seems better, but that's it.
[NI+ Alex to make sure he can take a look here.]
Flags: needinfo?(surkov.alexander)
I'm curious if Nightly got any better on this. Marco, can you give it a try?
Flags: needinfo?(surkov.alexander)
I used the page given by Mark in comment #16, about 10 minutes ago, and am just now back with a responsive browser. So while I no longer experience the 20 minutes Mark mentioned, it is still bad.
(In reply to Marco Zehe (:MarcoZ) from comment #34)
> I used the page given by Mark in comment #16, about 10 minutes ago, and am
> just now back with a responsive browser. So while I no longer experience the
> 20 minutes Mark mentioned, it is still bad.

so it's 2 times improvement, which sounds quite good. I'll take a look what further improvements can be taken.
Marco, do you know how good timing do dxr and searchfox pages have nowadays?
Flags: needinfo?(mzehe)
Really bad still. I used the DXR link given to me after I open Mark's URL from comment #16, and while initial Buffer load took 175.053 sec, 88742 chars, subsequent buffer re-renders caused the browser to freeze and become unusable for over 20 minutes. Until I decided to kill it from the task bar and got a crash when I did. Unfortunately, this was not caught by our crash reporter, only brought up the standard Windows dialog that something was wrong with Nightly and that it was being shut down.
Flags: needinfo?(mzehe)
You need to log in before you can comment on or make changes to this bug.