395619 - Unnacceptable find bar performance when a11y active

Status: RESOLVED DUPLICATE of bug 396005

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

With accessibility active, load
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsRootAccessible.cpp

Try to search using Ctrl+F and typing a phrase.

It either is incredibly slow or locks up.

This does not happen when accessibility is not active.

Comment 1

[Phil Ringnalda (:philor)]

Pretty sure you didn't mean to put this in Cmd-line Features :)

Comment 2

[Boris Zbarsky [:bzbarsky]]

For what it's worth, even loading that page with accessibility enabled pretty much locks up for me.  About 70% of the pageload time is spent under nsDocAccessible::FlushEventsCallback.  Most of that is spent under nsDocAccessible::CreateTextChangeEventForNode.  Lot of QI floating around, etc.  Is there a separate bug on that stuff?

Back to this bug, I can't seem to reproduce it reliably.  What phrase are you searching for?

Comment 3

[Aaron Leventhal]

Mozilla starts firing accessibility mutation and text change events once it 1) has a partial tree or 2) the page has fully loaded

#1 can happen early if there is any kind of focus, caret move or selection event in content

So, I think what's going on is that the new code to fire text change events is very expensive and if it starts happening before the page is fully loaded, it keeps calculating these events for every new bit of loaded content.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  Let's fix that, and see what happens here.  I filed bug 396005.

Comment 5

[Aaron Leventhal]

In fact it's the same bug. Patch in bug 396005.