1378235 - Consider caching the accessible name

Status: NEW

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

Description

[Joanmarie Diggs]

The rules for calculating the accessible name can be non-trivial. We should consider caching the accessible name once we've done the work. The tricky part will be to reliable catch all the conditions which should trigger marking the cached name dirty (especially in the case where the accessible name is constructed from multiple descendants).

Comment 1

[alexander :surkov (:asurkov)]

keep the cache updated can be a real challenge, and will have a perf impact as well. Do you have any data how slow we are on name computations?

Comment 2

[Joanmarie Diggs]

I agree regarding challenge, and I've not yet done any profiling on computations. And for what it's worth, I'm not saying Gecko is slow as much as I'm saying the AccName algorithm has the potential to be. (Every time I look at those steps in the spec, a little piece of me dies. But I digress....)

I'm surprised that it might have a perf impact. We already have to keep track of changes to the DOM, so I didn't think marking changed nodes as having a dirty name would be a noticeable hit. New contributor naïveté, perhaps?

That said, feel free to WONTFIX it. :)

Comment 3

[alexander :surkov (:asurkov)]

(In reply to Joanmarie Diggs from comment #2)

> I'm surprised that it might have a perf impact. We already have to keep
> track of changes to the DOM, so I didn't think marking changed nodes as
> having a dirty name would be a noticeable hit. New contributor naïveté,
> perhaps?

the devil in details, as you said the alg is quite branchy. For example, each accessible tree change will require us to crawl up the hierarchy to check whether it's part of name computation, for example, if there's a button on top, then mark its cached name dirty (or recache it - which is slow and no one might need it), if root has ID, then check if anyone in the DOM is referring to it, and so on.

Re-caching alg may be complex enough and it will have some perf print of course, might be not that bad as I'm drawing it.

> That said, feel free to WONTFIX it. :)

e10s cache may benefit from this change, so I'm not sure how to proceed with the proposal, but of course I'd wish to avoid this.