Closed
Bug 563331
Opened 14 years ago
Closed 12 years ago
Speed up or find alternative for HasRelatedContent/FindNeighbourPointingToNode
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: davidb, Assigned: davidb)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: perf)
Spin off from bug 538594. Brainstorm: What if we perform the FindNeighbourPointingToNode more lazily? Like during GetName and GetDescription? We could do it once and set a member flag on the accessible object? What if we just accept any node with an id? Probably the a11y tree will be too cluttered.
Comment 1•14 years ago
|
||
ARIA attributes (like aria-labelledby, aria-describedby and etc) are used to create accessible relations for accessibles, for example, <span id="label">it's a description</span> <input aria-describedby="label"> We need to get related accessibles each by other, i.e. in the example above we need to get span by input and input by span. As side effect of relation computation we make sure that node that is related with another one is accessible what leads perf problems since we inspect the subtree around the node to see if it has ARIA attribute. For example, mozilla mxr pages may be loading significant time. We could cache either accessible relations or DOM structures that allows us to find related nodes. We need to create relations when DOM document is loading. Also we need to use nsIMutationObserver to keep relation updated. The problem is if the document was loaded before a11y started then we need to either traverse the whole DOM document before accessible tree creation and cache relations or make sure we create whole accessible tree and remember elements with ID since they can be referred by ARIA attributes somewhere in the tree and then insert their accessibles into tree.
Summary: Speed up or find alternative for HasRelatedContent/FindNeighbourPointingToNode → cache relations defined by ARIA attributes
Comment 2•14 years ago
|
||
this bug has a twin bug 381599
Assignee | ||
Comment 3•14 years ago
|
||
I'm not sure I agree with the morphing of this bug. How about morphing it back and doing any relation caching on that twin bug?
Comment 4•14 years ago
|
||
(In reply to comment #3) > I'm not sure I agree with the morphing of this bug. How about morphing it back > and doing any relation caching on that twin bug? I'm fine with that.
Comment 5•14 years ago
|
||
done
Summary: cache relations defined by ARIA attributes → Speed up or find alternative for HasRelatedContent/FindNeighbourPointingToNode
Assignee | ||
Comment 6•14 years ago
|
||
Note Michael Kraft provides a good test case on dupe bug 581281: "http://mxr.mozilla.org/mozilla1.9.2/source/browser/base/content/browser.js#5822 and then click and drag on the page, the browser will hang nearly 100% of time." (He also graciously attaches a debug stack on that bug) Alexander did you start a WIP for this one yet? I'm leaning towards taking an ax to HasRelatedContent ;)
Severity: normal → major
Priority: -- → P2
Comment 8•14 years ago
|
||
(In reply to comment #6) > Alexander did you start a WIP for this one yet? I'm leaning towards taking an > ax to HasRelatedContent ;) No, especially if you keep this bug for functionality axing :) I'm planing to work on the problem in bug 573469.
Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #8) > (In reply to comment #6) > > Alexander did you start a WIP for this one yet? I'm leaning towards taking an > > ax to HasRelatedContent ;) > > No, especially if you keep this bug for functionality axing :) I'm planing to > work on the problem in bug 573469. Great!
Assignee | ||
Comment 10•14 years ago
|
||
Approving blocking2.0 (nomination migrated from dependency bug 573469).
blocking2.0: --- → final+
Keywords: perf
Assignee | ||
Comment 12•14 years ago
|
||
Weird. I'm having trouble getting HasRelatedContent or FindNeighbourPointingToNode to show up in profiling... Is this now a WFM?
Assignee | ||
Comment 13•14 years ago
|
||
Still not seeing this on xperf (sure wish it showed the call stack like shark).
Comment 14•14 years ago
|
||
(In reply to comment #12) > Weird. I'm having trouble getting HasRelatedContent or > FindNeighbourPointingToNode to show up in profiling... Is this now a WFM? It can't be wfm even you don't have steps to reproduce. Obviously we traverse large hung of DOM tree for every node under certain circumstances.
Comment 15•14 years ago
|
||
(In reply to comment #14) > (In reply to comment #12) > > Weird. I'm having trouble getting HasRelatedContent or > > FindNeighbourPointingToNode to show up in profiling... Is this now a WFM? > > It can't be wfm even you don't have steps to reproduce. Obviously we traverse > large hung of DOM tree for every node under certain circumstances. David, what's your testcase?
Assignee | ||
Comment 16•14 years ago
|
||
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > > Weird. I'm having trouble getting HasRelatedContent or > > > FindNeighbourPointingToNode to show up in profiling... Is this now a WFM? > > > > It can't be wfm even you don't have steps to reproduce. Obviously we traverse > > large hung of DOM tree for every node under certain circumstances. > > David, what's your testcase? I simply don't have a good test case. I tried mxr for large files. I'm still looking for a good test case.
Comment 17•14 years ago
|
||
I'm taking you can't reproduce this issue with the steps from comment #6?
Comment 18•14 years ago
|
||
(In reply to comment #17) > I'm taking you can't reproduce this issue with the steps from comment #6? btw, today I saw perf problem on mxr pages with FindDescedantPointingToID as pointed in summary of bug 581281 (inside of accessible name calculation). I was confused by this bug summary and therefore I said I wasn't able to reproduce this bug when I talk to David on irc today. I think the good testcase will be a huge amount of spans with ID.
Assignee | ||
Comment 19•14 years ago
|
||
(In reply to comment #17) > I'm taking you can't reproduce this issue with the steps from comment #6? That is correct, but I have only tried profiling with xperf. Michael can you still confirm the hang with Firefox trunk? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Comment 20•14 years ago
|
||
(In reply to comment #19) > That is correct, but I have only tried profiling with xperf. Michael can you > still confirm the hang with Firefox trunk? > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ No I can't get it to hang on the trunk load, but I never could even back when I filed bug 581281. It would freeze for about 10 seconds, but it would recover. Now there's no freeze at all (at least on the PC I'm using currently). Maybe it was "accidentally" fixed elsewhere or the new optimized JavaScript engine is really that much better.
Assignee | ||
Comment 21•14 years ago
|
||
Unblocking 2.0. We can reconsider if the severity resurfaces.
Severity: major → normal
blocking2.0: final+ → ---
Priority: P2 → --
Assignee | ||
Comment 22•14 years ago
|
||
I wonder if we can just check HasID for HTML, and keep our DOM look-around for XUL?
Assignee | ||
Comment 23•14 years ago
|
||
Note that question is for myself ;)
Comment 24•14 years ago
|
||
HasRelatedContent is much improved by bug 573469. We still get used to traverse the tree from bottom to top to search active descendants. FindNeighbourPointingToNode issue is fixed, it's completely removed in bug 381599. We need to estimate our resources and mark this bug blocking if we can fix it in reasonable time. This is really wanted, without it fixed we can't be fast.
Comment 25•12 years ago
|
||
eventually aria-activedescendant stuff referred in comment #24 were gone, not sure at which point. We can close this bug as worksforme.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•