Open Bug 759236 Opened 12 years ago Updated 1 year ago

a11y::TreeWalker timer is blocking the main thread

Categories

(Core :: Disability Access APIs, defect, P3)

x86
macOS
defect

Tracking

()

People

(Reporter: BenWa, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, regression, Whiteboard: [mac2020_2] )

I noticed a lot of Jank in the last hour with my nightly build. I haven't used anything accessibility related but I have been using the Web Inspector.

http://varium.fantasytalesonline.com/cleopatra/?report=AMIfv97P-MAA4aUL8Q21q48mUxq8jXlLyUjTtB4fMMeWXpqJtKu-zuLLXprtE3dU-ZfOU5tSF5uZTIlFty8PovNNdoCJJGRfq9GJDIfj49VYZ0FgbpVQoF-bHkFeTBaehKxYVlvmPXKmoRRJBOwp7h3JaBkyOzxi3w
Do you have any steps to reproduce so I can play on my machine?
Unfortunately no so I hesitated to file this bug. All I know is I was using the Web Inspector heavily to inspect the document and changed the style of the page.

Let me know if you have any questions about how to understand the profile link posted above.

What reason would nsDocAccessible::ProcessContentInserted be running in a nightly build in a timer? I haven't noticed this function in my profiles before.
(In reply to Benoit Girard (:BenWa) from comment #2)

> What reason would nsDocAccessible::ProcessContentInserted be running in a
> nightly build in a timer? I haven't noticed this function in my profiles
> before.

We do accessible tree update by adding a refresh observer (mPresShell->AddRefreshObserver with Flush_Display). Cc'ing Boris since he should know better than me if anything was changed.
Benoit we turned FF a11y support on a few weeks ago and you are probably using something or have some OSX configuration that invokes Mac a11y and thereby our engine. You wouldn't have seen a11y show up in your profiling previously.
So the real question is "why does nsDocAccessible::ProcessContentInserted take so long (is that JS execution I see under there?) and what can be done to fix that?"
No, I think the question was related with interuptable reflow. Say two nested subtrees are inserted like

  subtree1
    subtree2

if subtrees are constructed at once and a11y gets one nsCSSFrameConstructor::ContentRangeInserted for subtree1 then we construct a11y tree for subtree1 and subtree2. But if a11y gets two notifications, one for subtree1, another one for subtree2 and refresh observer triggers for these notifications separately (i.e. between them) then it should be less noticeable for the user. So the question was if anything on this way was changed (for example, previously we get two notifications, now we get only one)?

But actually I think the problem was discovered because a11y was enabled on mac by default as David said.

Anyway,
1) we should make nsDocAccessible::ProcessContentInserted fast as possible
2) and/or make interruptible a11y tree creation to not block main thread. 

For 2nd how do you handle frames tree creation which are expensive to not block main thread for a long time?
> No, I think the question was related with interuptable reflow.

I don't see any mention of interruptible reflow here.

> So the question was if anything on this way was changed

Nope.

> But actually I think the problem was discovered because a11y was enabled on mac by
> default as David said.

Agreed.

> 1) we should make nsDocAccessible::ProcessContentInserted fast as possible

Yes.

> For 2nd how do you handle frames tree creation which are expensive

They block the main thread for a long time.
FWIW David checked out my configuration today and found that I had 'Enable access for assistive devices' enabled. This was enabled when I installed 'SizeUp' http://www.irradiatedsoftware.com/sizeup/. I suspect we have a large number of users with this setting turned on.
I'm still getting 1+ second hands when loading gmail and other site. It would be nice to have a solution before uplifting.
Keywords: regression
Solution is to disable os x a11y for aurora and etc. 

Who is on it?
and disable the test at the same time, only on Aurora.
see bug 761256 to disable a11y on Mac in Aurora
Depends on: 761256
Alexander - who would be in the best position to look into this?

This may block enabling Aurora 15 updates - please prioritize the investigation highly.
Assignee: nobody → surkov.alexander
if you approve bug 761256 for Aurora, this will go away... (no fixed, just go away).
No longer relevant in Firefox 15. Still need to investigate for FF16.
(In reply to Alex Keybl [:akeybl] from comment #13)
> Alexander - who would be in the best position to look into this?

It's on my plate for now. It's not easy to fix and the fix should take a time since we need to rethink how we create accessible tree.

> This may block enabling Aurora 15 updates - please prioritize the
> investigation highly.

It shouldn't block Aurora since Hub disabled mac a11y in bug 761256.
(In reply to alexander :surkov from comment #16)
> > This may block enabling Aurora 15 updates - please prioritize the
> > investigation highly.
> 
> It shouldn't block Aurora since Hub disabled mac a11y in bug 761256.

Agreed - thanks all
Summary: nsAccTreeWalker timer is blocking the main thread → a11y::TreeWalker timer is blocking the main thread
Keywords: perf
Whiteboard: [mac2020_2]
Priority: -- → P3

We should check if this is still at all relevant in light of E10S as well as bug 1618364.

Severity: normal → S3

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: surkov.alexander → nobody
You need to log in before you can comment on or make changes to this bug.