1412946 - consider lazy accessible document creation

Status: NEW

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

Description

[alexander :surkov (:asurkov)]

The rule may be simple for the start: create a document accessible only if it's hosted by active tab, and ignore all background tabs. The approach is not backward compatible and known for breaking certain softwares: see 1329977#c20 for example, so we need to figure out how to workaround that.

Alex, is it possible to retrieve same information having no documents for background tabs?

Comment 1

[Alex Vallat]

If a background tab does not have a document accessible created for it, it will not be possible to produce a list of open URLs, or to include URL of each tab in the list of tabs (unless this information is added elsewhere higher up the hierarchy, of course).

Although it would (slightly) negatively impact one specific use case of mine, my personal opinion is that this would be acceptable behaviour. Accessibility is supposed to be for describing what is shown on the screen, and while it is convenient to be able to give the URL rather than just the title of background tabs, it's arguably not important to do so if it causes performance problems.

Comment 2

[alexander :surkov (:asurkov)]

Thank you, Alex.

Here's a bunch of options to think about:
* restrict document creation only to active documents (a super easy and the most performant path)
* create a document for a background tab but no content; that would help with Alex's case, and probably will be less confusing, but harder to implement, and a little bit less performant than it could be
* do not create a document and content in background tabs until AT tried to fetch them (might be a bit tricky to implement and error prone in general)

Jamie, can I grab your thinking on this?

Comment 3

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #2)
> * restrict document creation only to active documents (a super easy and the
> most performant path)

1. Given Alex V's explanation, I think this sounds reasonable.
2. Having said that, we need to be careful about the definition of active tab. The document should be created even if a focus (or some other) event wasn't fired since a11y was instantiated. Before the patch for bug 1329977, that wasn't happening. It's entirely possible (and valid) that a client might make the first query *after* the tab got focus.
3. If a client makes a strong argument for having the URL, I can see some validity in having it somewhere else in the hierarchy. That should be dealt with in a separate bug of course.

> * create a document for a background tab but no content; that would help
> with Alex's case, and probably will be less confusing, but harder to
> implement, and a little bit less performant than it could be

In one sense, it's less confusing. However, it might also seem as if it's just an empty document, rather than an unloaded document. Given that this is probably tricky to implement, I think I prefer the earlier option. At least the situation is clear.

> * do not create a document and content in background tabs until AT tried to
> fetch them (might be a bit tricky to implement and error prone in general)

This sounds nice in theory, but I agree that there are all sorts of potential problems there. Clients would certainly need ot deal with async behaviour. Also, there's a lot more room for clients causing performance problems by poking the tree when they don't really need to, and unfortunately, we have seen strange clients carelessly traverse like this. Having said that, we should consider this option if a client makes a strong case for it in the future.

So, weighing up all the options, I think the first option makes the most sense, given current client requirements.

Comment 4

[alexander :surkov (:asurkov)]

ok, let's stick with option #1 then, taking DocShell::IsActive [1] for 'active document' definition, I think it matches to a document loaded in a current tab.

[1] https://dxr.mozilla.org/mozilla-central/source/obj-x86_64-pc-linux-gnu/dist/include/nsIDocShell.h#439

Comment 5

[James Teh [:Jamie]]

This is going to get even messier with Fission, since a top level document in a content process might actually be an iframe. Such a document might not receive focus or any other notification, but it still needs to be accessible in the tree for the active tab document. Even if we did notify all OOP iframe documents when their tab got activated, we'd need to tweak a lot of things to ensure the a11y tree was linked correctly, especially on Windows. Dropping priority.