Cache LABELLED_BY relation
Categories
(Core :: Disability Access APIs, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: morgan, Assigned: morgan)
References
Details
(Whiteboard: [ctw-m2])
Attachments
(4 files, 2 obsolete files)
This is the relation Windows depends on the most, so we should cache this first :)
Assignee | ||
Comment 1•2 years ago
•
|
||
Last CtW meeting we discussed caching one of the label for/labelled by pair and computing the reciprocal relation in the parent process.
I thought about this some more today and am confused about how we handle the "attribute removed" case.
Say, for example, we have the following:
<div id="d1">hello</div>
<button aria-labelledby="d1"></button>
Let's also assume we're caching the labelled by relation and computing the label for relation.
We'll update our cache with a DeleteEntry()
for labelled by on the button, but how do we know (in parent) that we need to remove the div's label for relation? Outside of DOMAttributeChanged
I don't think we have access to the old value of aria-labelledby
...
:Jamie do you have thoughts on this? I don't really see a way forward here, apart from caching both relations independently (then, when we see aria-labelledby
removed in DOMAttributeChanged
, we'd use the old value to somehow fetch the acc(s) that used to act as labels, and push DeleteEntry()
s for their label for relations too. I imagine there's a hash-map-y way around this, but I'm just not seeing it right now :(
Also: I think this problem also exists if we end up caching the label for relation instead, if that node gets destroyed, or its ID changes, we still need to be able to update the reciprocal relation.
Comment 2•2 years ago
|
||
Hmm. Tricky.
My initial thinking was that we have the old value in mCachedFields, so we can just use that to compare against. Unfortunately, the cache update logic is isolated to AccAttributes::Update, which doesn't (and shouldn't) know anything about RemoteAccessibles, relations, etc.
Moving the update code into RemoteAccessibleBase::ApplyCache would make this easier, but it's also horrible and will probably require yucky messing with making other AccAttributes things public or friend classes or the like. On the flip side, it would avoid extra hash lookups.
Another alternative could be to have AccAttributes::Update take a lambda which takes the key being updated/removed, giving the caller the chance to do some pre-processing if that key is present. If this lambda sees labelledBy, it would remove the labelFor data for the target Accessibles for the pre-update labelledBy (i.e. the labelledBy still in mCachedFields). It would also set a flag so it knows to update labelFor on the new targets.
A final option could be to check for the presence of labelledBy in aFields in RemoteAccessibleBase::ApplyCache before we call mCachedFields->Update. If present (either an update or a delete), we remove the labelFor data for the target Accessibles for the pre-update labelledBy (i.e. the labelledBy still in mCachedFields). We then call mCachedFields->Update. After that, we update the labelFor on the new labelledBy targets. This does involve additional hash lookups for every cache update, though. I'm not sure if that is premature optimisation or not.
Assignee | ||
Comment 3•2 years ago
|
||
Assignee | ||
Comment 4•2 years ago
|
||
Depends on D151881
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
Assignee | ||
Comment 7•2 years ago
|
||
Depends on D152100
Assignee | ||
Comment 8•2 years ago
|
||
Depends on D152101
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Backed out for causing build bustages.
Backout link: https://hg.mozilla.org/integration/autoland/rev/4eeee5a6274709c9aad68cc34c03631da9c57d2e
Failure log: https://treeherder.mozilla.org/logviewer?job_id=385502594&repo=autoland&lineNumber=9976
Updated•2 years ago
|
Updated•2 years ago
|
Comment 11•2 years ago
|
||
Assignee | ||
Comment 13•2 years ago
|
||
clean try: https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=WZhEYKPGSJOfmZQLBoQvcA.0&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cusercancel%2Crunning%2Cpending%2Crunnable&revision=d552ef44da1dc65906e5d440d7743e2d0c6d13a9
(one failure is unrelated, known intermittent)
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6de77a6f3d23
https://hg.mozilla.org/mozilla-central/rev/570aa988c8c8
https://hg.mozilla.org/mozilla-central/rev/dd760c44c8ba
https://hg.mozilla.org/mozilla-central/rev/063973343a0e
Description
•