Open Bug 1412946 Opened 4 years ago Updated 2 years ago
consider lazy accessible document creation
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?
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.
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?
(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.
ok, let's stick with option #1 then, taking DocShell::IsActive  for 'active document' definition, I think it matches to a document loaded in a current tab.  https://dxr.mozilla.org/mozilla-central/source/obj-x86_64-pc-linux-gnu/dist/include/nsIDocShell.h#439
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.