1885547 - Add test for a11y relations for "modern" tab prompts

Status: RESOLVED FIXED

(Toolkit :: Content Prompts, task)

Description

[:Gijs (away/busy until Mar 10)]

In bug 1705440 I'm removing an old test for the tabmodalprompt XBL binding prompt implementation. It seems there's no equivalent for the current set of prompts. Feels like having a test for this might be useful.

Comment 1

[James Teh [:Jamie]]

Capturing this from a conversation on Matrix so we don't lose it.

IIUC that test is effectively testing a) whether we get the right events and b) whether the dialog has a correct relation pointing at the dialog message (description). I can't think of a test that's quite like that, but a browser test like this should do the trick (completely untested):

addAccessibleTask(``, async function (browser) {
  info("Showing alert");
  let shown = waitForEvent(EVENT_SHOW, evt => evt.accessible.role == ROLE_DIALOG);
  await invokeContentTask(browser, [], () => {
    content.alert("test");
  });
  // Let's make sure the button gets focus.
  let focused = waitForEvent(EVENT_FOCUS, evt => evt.accessible.role == ROLE_BUTTON);
  const dialog = (await shown).accessible;
  await focused;
  ok(true, "Dialog shown and button focused");
  testRelation(dialog, RELATION_DESCRIBED_BY, "infoBody");
  testDescr(dialog, "test");
  info("Dismissing alert");
  let hidden = waitForEvent(EVENT_HIDE, dialog);
  EventUtils.synthesizeKey("KEY_Return");
  await hidden;
});

Comment 2

[:Gijs (away/busy until Mar 10)]

Attachment: Bug 1885547 - add a11y test for prompt relations, r?Jamie

Comment 3

[:Gijs (away/busy until Mar 10)]

I tried to adapt your suggestion (see attached WIP patch) but I'm seeing that the frame is causing events with role ROLE_INTERNAL_FRAME and ROLE_LABEL, but not ROLE_ALERT or ROLE_DIALOG. Although SubDialog sets role=alertdialog (bug 1660365) that doesn't appear to be in time for this event. What I'm not sure about is if that is something that we need to fix (and if so, how - set a role on the browser?) or if that's a test expectation we could/should adapt. I'm hoping that if it's a problem then we would have caught it in 1660365, but I don't know enough about a11y events to be sure. Jamie? :-)

Comment 4

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #3)

I tried to adapt your suggestion (see attached WIP patch) but I'm seeing that the frame is causing events with role ROLE_INTERNAL_FRAME and ROLE_LABEL, but not ROLE_ALERT or ROLE_DIALOG. Although SubDialog sets role=alertdialog (bug 1660365) that doesn't appear to be in time for this event.

I think what's happening here is that from the a11y engine's perspective, the <browser class="dialogFrame" ...> gets shown and it already contains the <window id="commonDialogWindow" ...>. The a11y engine only fires a show event for the root of a newly shown subtree.

That's going to make this test more annoying to write because it'll have to be somewhat dependent on this implementation detail, but it is what it is. I'd probably do something like this (again completely untested):

...
  let shown = waitForEvent(EVENT_SHOW, evt => evt.accessible.role == ROLE_INTERNAL_FRAME);
  await invokeContentTask(browser, [], () => {
    content.alert("test");
  });
  // Let's make sure the button gets focus.
  let focused = waitForEvent(EVENT_FOCUS, evt => evt.accessible.role == ROLE_BUTTON);
  const frame = (await shown).accessible;
  const button = (await focused).accessible;
  ok(true, "Alert shown and button focused");
  // Make sure we correctly expose dialog semantics.
  const dialog = button.parent;
  testRole(dialog, ROLE_DIALOG);
  testRelation(dialog, RELATION_DESCRIBED_BY, "infoBody");
  testDescr(dialog, "test");
  info("Dismissing alert");
  let hidden = waitForEvent(EVENT_HIDE, frame);
...

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84babf8e4e49
add a11y test for prompt relations, r=Jamie

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/84babf8e4e49