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

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[noitidart]

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

Comment 1

[noitidart]

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

Comment 2

[Loic]

Do you have crash reports (bp-...) related to this issue in about:crashes?

Comment 3

[noitidart]

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

Comment 4

[Loic]

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).

Comment 5

[Paul Silaghi, QA [:pauly]]

Everything's fine for me on http://doxygen.reactos.org/files.html on 36b1, 38.0a1 (2015-01-19) Win 7

Comment 6

[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.

Comment 7

[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

Comment 8

[noitidart]

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)

Comment 9

[Gabriela [:gaby2300]]

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

Comment 10

[noitidart]

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

Comment 11

[Nickolay_Ponomarev]

> 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

Comment 12

[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

Comment 13

[noitidart]

oh correction it didnt crash but it hung forever, so i had to ctrl+alt+del and force quit due it not crashing

Comment 14

[Vlad Bacia-Mociran [:VladB]]

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

Comment 15

[Vlad Bacia-Mociran [:VladB]]

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.

Comment 16

[Mark Straver]

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.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

(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

Comment 18

[Mark Straver]

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

Comment 19

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 20

[Mark Straver]

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.

Comment 21

[Mark Straver]

Also, apologies for half-hijacking this bug, as it turned out to be something completely different than a scrolling hang.

Comment 22

[Vlad Bacia-Mociran [:VladB]]

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

Comment 23

[Mark Straver]

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.

Comment 24

[Mike Conley (:mconley) (:⚙️)]

Clearing needinfo, as we're waiting on Mark to report back.

Comment 25

[Mark Straver]

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.

Comment 26

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 27

[Mark Straver]

Loaded nightly, first verified the problem persisted -- it did.
Set accessibility.force_disabled to 2, problem went away.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

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 ?

Comment 29

[Trevor Saunders (:tbsaunde)]

> 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.

Comment 30

[Mike Conley (:mconley) (:⚙️)]

(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?

Comment 31

[Trevor Saunders (:tbsaunde)]

(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.

Comment 32

[David Bolter [:davidb] (NeedInfo me for attention)]

[NI+ Alex to make sure he can take a look here.]

Comment 33

[alexander :surkov (:asurkov)]

I'm curious if Nightly got any better on this. Marco, can you give it a try?

Comment 34

[Marco Zehe (:MarcoZ)]

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.

Comment 35

[alexander :surkov (:asurkov)]

(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.

Comment 36

[alexander :surkov (:asurkov)]

Marco, do you know how good timing do dxr and searchfox pages have nowadays?

Comment 37

[Marco Zehe (:MarcoZ)]

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.

Comment 38

[James Teh [:Jamie]]

This isn't actionable because the URLs included in this bug either no longer exist or no longer cause problems. There have been a lot of performance improvements since comment 37 thanks to Cache the World (bug 1694563). For any remaining performance problems, please open a new bug.