BUILD: Current trunk build STEPS TO REPRODUCE: 1) Enable accessibility 2) Load https://bugzilla.mozilla.org/attachment.cgi?id=375600 3) Click an of the buttons labeled "Delete" on the far right in the testase EXPECTED RESULTS: The time reported for "lazy tasks" should be measured in tens of milliseconds. The total time should be comparable to the page load time. ACTUAL RESULTS: The time reported for "lazy tasks" is measured in tens of seconds (at least on Windows). The total time is much larger than the pageload time (also on Mac). DETAILS: At least on Mac, it looks like all the editor setup that happens is made ridiculously slow by the nsDocAccessible::InvalidateCacheSubtree that triggers on all sorts of mutations. We're firing ValueChangeForTextfields, delayed accessible events (both signatures). We're doing this at least twice per textnode: once on editor init, and once on value set.
Boris, is there a way we can be notified of a whole document reframe begin and end? What triggers a whole document reframe?
When I say "whole document" here, I just mean all the visible content. Specifically, the <div id="AJAXdiv"> is what gets reframed in this testcase.
Depends on: 531850
Note: the test case in Step 2 has been greatly mitigated, probably by Ehsan's lazy editor init work. We do have a fair bit of lazy task though.
(In reply to comment #3) > Note: the test case in Step 2 has been greatly mitigated, probably by Ehsan's > lazy editor init work. We do have a fair bit of lazy task though. Hmm actually the lazy task time is roughly equivalent with a11y on and off.
Given that the case in comment 0 is mitigated, and that we have a number of bugs reported that cover our performance problem during/after reframes, I think we can close this one. Please reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.