1954415 - Consider dropping the browser argument to a11y browser test tasks in favour of getting the BrowsingContext from the doc acc

Status: NEW

(Core :: Disability Access APIs, task)

Description

[James Teh [:Jamie]]

Even when a test is run in an iframe, accessibility browser tests added using addAccessibleTask are provided with the top level browser element as an argument. This means that the browser argument can't be used directly when we want to reference the iframe context for functions like SpecialPowers.spawn. We have various wrapper functions such as invokeContentTask which work around this by searching for the iframe using a hard-coded id. However, there are times when we need to call other functions that need a BrowsingContext such as BrowserTestUtils.synthesizeMouseAtPoint.

In bug 1950740, I added a browsingContext attribute to nsIAccessibleDocument to allow the BrowsingContext to be retrieved for a DocAccessible when using XPCOM. This makes it possible to get the BrowsingContext when a test is run in an iframe by using docAcc.browsingContext. However, tasks are still provided with the top level browser as an argument.

When a test is run in an iframe, we should consider changing addAccessibleTask to pass the BrowsingContext for the iframe instead. This would make things more straightforward and would allow us to remove invokeContentTask in favour of the more standard SpecialPowers.spawn.

An obstacle to doing this is that we have quite a lot of calls to SpecialPowers.spawn in our tests (136 currently). Most (90) of these are in mac tests. I suspect many of these cases are just never run in an iframe, so it doesn't make any difference. However, for cases which do run in an iframe, we are deliberately choosing to run the task in the top level document, so changing the BrowsingContext we pass will break these. We'll need to look at these cases to determine which they are. For cases where we deliberately want to run the task in the top level document, we can change these to use browser.top, which will get the top level BrowsingContext. We can leave the others alone.

We may also want to rename the browser argument to browsingContext for correctness, but that would result in many lines of code changed (1671 lines with some very rough grepping, but that's likely inaccurate).

Comment 1

[James Teh [:Jamie]]

On further thought, since you can get the browsingContext from the docAcc anyway, we should just remove the browser argument and use docAcc.browsingContext (or docAcc.browsingContext.top or topDocAcc.browsingContext) instead. This makes it very explicit what browsingContext we're talking about.