1893376 - Failing WPT html-aam/fragile/area-role.html

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Thomas Wisniewski [:twisniewski]]

See https://wpt.fyi/results/html-aam/fragile/area-role.html

We seem to be failing this because there is no accessible node being generated for the <area> elements. If I remove this line, then the test passes: https://searchfox.org/mozilla-central/source/accessible/html/HTMLImageMapAccessible.cpp#103

Jamie, I take it that not setting that flag might cause other problems? If so, how might we resolve this?

Comment 1

[James Teh [:Jamie]]

I'm not entirely sure what problems removing that flag might cause, but I do know for certain that HTML areas are managed by their image map parent in the a11y engine. Among other things, removing this would probably cause problems when there are areas managed by multiple image maps.

We could try changing this line to use DocAccessible::GetAccessibleEvenIfNotInMap instead of just GetAccessible:

NS_IF_ADDREF(*aAccessible = ToXPC(document->GetAccessibleEvenIfNotInMap(aNode)));

However, I don't know if that has any implications for other tests in our own test suites.

Comment 2

[Thomas Wisniewski [:twisniewski]]

I just did a mach try auto run with your proposed change, and it didn't uncover any failing tests. Are there any others we ought to run there, or is it worth giving your proposed change a shot as-is? https://treeherder.mozilla.org/jobs?repo=try&author=twisniewski%40mozilla.com

Comment 3

[James Teh [:Jamie]]

I'm not great at reading try runs with that many jobs, but it looks to me like auto didn't choose the mochitest-a11y-1proc or mochitest-a11y-browser jobs. We should definitely run those. Sorry if I'm misreading the job list and they did run. (I don't tend to have much luck with mach try auto for a11y stuff lately.)

Anyway, if those (plus WPT, which did run) pass, I think we're good to give this a shot.

Comment 4

[Thomas Wisniewski [:twisniewski]]

Hmm, yeah, i'm not sure if they ran, and adding them to with the treeherder interface was being a pain, so I submitted a second try-run with mach try fuzzy: https://treeherder.mozilla.org/jobs?repo=try&revision=2ea721812def52cd1357e26e135de366fd6074fd

Comment 5

[Thomas Wisniewski [:twisniewski]]

Alright, that try-run seems green to me, so if you're willing to go ahead with this then just let me know and I can land it. (Or if you're not sure, we could always add a pref to have an easier way to toggle back to the previous behavior?)

Comment 6

[James Teh [:Jamie]]

I don't think this needs a pref if it works on try. The XPCOM stuff is test/WebDriver only, so if the tests aren't breaking, nothing else should either. Please go ahead.

Comment 7

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1893376 - have XPCOM GetAccessibleFor return GetAccessibleEvenIfNotInMap when getting an Accessible for a DOM node; r?jamie

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d4edb3fef3bd
have XPCOM GetAccessibleFor return GetAccessibleEvenIfNotInMap when getting an Accessible for a DOM node; r=Jamie

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d4edb3fef3bd