772900 - Browser not responding at http://www.stopforumspam.com/spamdomainsandips

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[netvope]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120711 Firefox/15.0a2
Build ID: 20120711042007

Steps to reproduce:

1. Start a new Firefox profile in Firefox 15.0a2 (2012-07-11)
2. Visit http://www.stopforumspam.com/spamdomainsandips
3. Wait for a while


Actual results:

Browser hangs, window title says "not responding"


Expected results:

Browser does not hang

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

I see no Browser Hang but that may be dependent on CPU Power.

FWIW, here is a Profile: http://people.mozilla.com/~bgirard/cleopatra/?report=35689fc07f41d3fed8e998418b048518fa4ff862 against Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120713030548.

Large Time spent in Reflow as it seems.

Comment 2

[netvope]

You're correct. With version "15.0a2 (2012-07-13)", it took the browser 4 min 40 sec to render the page on a AMD Phenom II X6 1055T.

In that 4 min 40 sec, the window is "Not Responding" and looks like this:

http://img.ctrlv.in/500166e776025.jpg

I cannot close the tab, create new tabs or do anything in Firefox. Task Manager also say "firefox.exe" is not responding. The only thing that can be done (other than to wait) is to kill the process.

Comment 3

[netvope]

In comparison, on the same machine, both IE 9 and Chrome 20 took less than 10 seconds to render the page, and were never "Not Responding" in the process.

Comment 4

[Boris Zbarsky [:bzbarsky]]

That's really bizarre.  I just tried an Aurora build which should approximately match the one comment 2 is about (though on Mac), and the page renders in about 5-6 seconds and is responsive throughout.

I wonder what's going on here.  It sure seems like it's not just layout...

netvope, do you see the same behavior in safe mode?

Comment 5

[netvope]

So I went to safe mode

The first time the page loaded in about 60 seconds
The second time it took about 5 min 20 seconds...

Comment 6

[Boris Zbarsky [:bzbarsky]]

That's really weird.

Can you reproduce that with a Nightly build too?  If so, would you be willing to create a profile following the directions at https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler and posting the link here?

Comment 7

[netvope]

I can reproduce it 2 out of 3 tries with Nightly 16.0a1 (2012-07-15)

Here is what I did:
1. I downloaded Nightly and installed the profiling add-on
2. Visited the problem site; the browser was not responsive for about 30 seconds
3. Uploaded profiling results: http://people.mozilla.com/~bgirard/cleopatra/?report=35a423a9b36c632bbf44c23e9ef4386c4fe704e6
4. Restarted Nightly
5. Visited the problem site; the browser was not responsive for a longer time (I forgot to time it)
6. Uploaded profiling results: http://people.mozilla.com/~bgirard/cleopatra/?report=1e9c4801c7d2747baa972a2002d6fbec239b3a1d
7. Restarted Nightly
8. Visited the problem site; the browser loaded the page in just a few seconds; it was responsive throughout.
9. Uploaded rofiling results: http://people.mozilla.com/~bgirard/cleopatra/?report=a7fd78b7f5001a883a13a14621470bd22af25c15

Comment 8

[netvope]

Forgot to mention it was tested with a clean profile. Point #1 should be:
1. I downloaded Nightly, created a new user profile and installed the profiling add-on

Comment 9

[Boris Zbarsky [:bzbarsky]]

Perfect, thanks!

The profiles from when your browser was unresponsive show all the time being spent under NotificationController::WillRefresh, and in particular under DocAccessible::UpdateTree.

I have no idea why this takes as long as it does, but clearly something is broken there.  And the reason I'm not seeing it is presumably that I don't have the accessibility code running.  It might be running in your case for various reasons: there are some applications and drivers (e.g. pen input devices) that force accessibility code on for Windows....

In any case, over to the right component.  ;)

In the meantime, you should be able to work around this locally by setting the "accessibility.force_disabled" preference to 1 in about:config, if you're not actually relying on the accessibility code.

Comment 10

[(mostly gone) XtC4UaLL [:xtc4uall]]

There's also a recently added "Accessibility" Section in "about:support" telling its States.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Boris Zbarsky (:bz) from comment #9)
> Perfect, thanks!
> 
> The profiles from when your browser was unresponsive show all the time being
> spent under NotificationController::WillRefresh, and in particular under
> DocAccessible::UpdateTree.

I was searching nsRefreshDriver::Notify which calls layout::FlushPendingNotification and NotificationController::WillRefresh as well. It says the time spent on layout::FlushPendingNotification is 73% (vs 23% spent on WillRefresh). Did you mean that a11y makes running that FlushPendingNotification somehow?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Alexander, which profile are you looking at?  And which part of the profile?

I am looking at http://people.mozilla.com/~bgirard/cleopatra/?report=1e9c4801c7d2747baa972a2002d6fbec239b3a1d and in particular at the long red (unresponsive) chunk.  In that chunk, 100% of the time under Notify is spent under NotificationController::WillRefresh.

Comment 13

[netvope]

(In reply to Boris Zbarsky (:bz) from comment #9)
> Perfect, thanks!
> 
> The profiles from when your browser was unresponsive show all the time being
> spent under NotificationController::WillRefresh, and in particular under
> DocAccessible::UpdateTree.
> 
> I have no idea why this takes as long as it does, but clearly something is
> broken there.  And the reason I'm not seeing it is presumably that I don't
> have the accessibility code running.  It might be running in your case for
> various reasons: there are some applications and drivers (e.g. pen input
> devices) that force accessibility code on for Windows....
> 
It sounds like there is an per-application or system-wide "accessibility mode" that is somehow turned on in my case. What is the technical name for that mode or API? I'm interested and want to understand more.

> In any case, over to the right component.  ;)
> 
> In the meantime, you should be able to work around this locally by setting
> the "accessibility.force_disabled" preference to 1 in about:config, if
> you're not actually relying on the accessibility code.
>
The workaround works. Thank you.

Comment 14

[Boris Zbarsky [:bzbarsky]]

There's an internal mode for our app.  We turn on accessibility code if something uses MSAA (http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility ) to query us for data, or if our internal accessibility APIs are used (e.g. some of our debugging tools can trigger those).

Chances are, something on your system is calling into us via MSAA.  Again, some device drivers are known to do this, and also some third-party apps that try to interrogate everything on the system.

In terms of naming, we don't really have a name for this mode other than "accessibility enabled"....

Comment 15

[Wayne Mery (:wsmwk)]

http://www.stopforumspam.com/spamdomainsandips works great for me with current nightly. accessibility.force_disabled = 0

Does anyone still see the problem?