NEW
Unassigned

Status

()

Core
Disability Access APIs
6 years ago
a year ago

People

(Reporter: netvope, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug, {perf})

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sps])

(Reporter)

Description

6 years ago
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
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.
Component: Untriaged → Layout
Keywords: perf
Product: Firefox → Core
Version: 15 Branch → Trunk
(Reporter)

Comment 2

6 years ago
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.
(Reporter)

Comment 3

6 years ago
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.
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?
(Reporter)

Comment 5

6 years ago
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...
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?
(Reporter)

Comment 7

6 years ago
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
(Reporter)

Comment 8

6 years ago
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
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.
Status: UNCONFIRMED → NEW
Component: Layout → Disability Access APIs
Ever confirmed: true

Updated

6 years ago
Whiteboard: [sps]
There's also a recently added "Accessibility" Section in "about:support" telling its States.

Comment 11

6 years ago
(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?
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.
(Reporter)

Comment 13

6 years ago
(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.
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"....

Updated

5 years ago
Blocks: 531850
http://www.stopforumspam.com/spamdomainsandips works great for me with current nightly. accessibility.force_disabled = 0

Does anyone still see the problem?
Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.