1622346 - Intermittent focus/the-autofocus-attribute/first-when-later-but-before.html.ini WPT FAIL

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Chris Peterson [:cpeterson]]

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/html/interaction/focus/the-autofocus-attribute/first-when-later-but-before.html.ini

if (os == "win") and fission and webrender and not debug: ["PASS", "FAIL"]

Comment 1

[Chris Peterson [:cpeterson]]

The DOM Fission team is relying on feature teams to debug and fix Fission failures in their tests. If the failure looks like a bug in Fission's DOM or IPC changes, you can send the bug back to me.

We're hoping to enable Fission for a subset of Nightly users in early Q3, so we would like WPT tests to be green for Fission by end of Q2. Whether a particular test failure actually blocks shipping Fission is up to the discretion of the feature team. You all would know better than the DOM Fission which test failures are most important.

You can enable Fission when running WPT tests locally using mach wpt --enable-fission.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Henri, please help us to understand the importance and priority of this if you see fit. Thank you.

Comment 3

[Henri Sivonen (:hsivonen)]

It's bad to have something that fails depending on timing (probably depends on the relative order of the content process believing it that it is OK for it to take focus and the code that tries to take focus running). However, the user impact is minimal, and since we have bigger problems with Fission focus right now, I think this is practically P3, but we should do a retriage round of the various test failures when the bigger problems have been dealt with, and I'd expect to upgrade this in such a later triage round.

As far as I can tell, this isn't a test bug but an actual Gecko bug. We'll probably want to make the autofocus triggering code ask the focus manager if we're in a state where focus can be taken and post a runnable to retry on the next event loop spin if not. That's not a great solution, and I'd welcome better ideas. Also, it would be super-nice to see this in Pernosco, which would require a Linux repro.

Comment 4

[Chris Peterson [:cpeterson]]

Tracking WPT Fission bugs for Fission M6b (Q2)

Comment 5

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 6

[Chris Peterson [:cpeterson]]

This test still fails intermittently for Fission on Windows, but it also fails intermittently for non-Fission on Linux and Android.

https://searchfox.org/mozilla-central/rev/35b97af64a55d1d30caa4d6e9fabc1a7fbabc509/testing/web-platform/meta/html/interaction/focus/the-autofocus-attribute/first-when-later-but-before.html.ini

    expected:
      if (os == "win") and fission: ["PASS", "FAIL"]
      if (os == "linux") and not debug: ["PASS", "FAIL"]
      if (os == "android") and not debug: ["PASS", "FAIL"]

Comment 7

[Neha Kochar [:neha]]

Henri, can you please re-evaluate this failure for Fission Nightly experiments?

Comment 8

[Henri Sivonen (:hsivonen)]

Oops. I didn't mean to clear the needinfo yet.

Comment 9

[Henri Sivonen (:hsivonen)]

The test relies on this:

// If an element with autofocus is connected to a document and this function
// is called, the autofocus result is deterministic after returning from the
// function.
// Exception: If the document has script-blocking style sheets, this function
// doesn't work well.
async function waitUntilStableAutofocusState(w) {
  let targetWindow = w || window;
  // Awaiting one animation frame is an easy way to determine autofocus state.
  await waitForAnimationFrame(targetWindow);
}

It's unclear to me if Gecko makes any guarantees that the above should work.

Comment 10

[Henri Sivonen (:hsivonen)]

Where waitForAnimationFrame is:

function waitForAnimationFrame(w) {
  let targetWindow = w || window;
  return new Promise((resolve, reject) => {
    targetWindow.requestAnimationFrame(resolve);
  });
}

Comment 11

[Henri Sivonen (:hsivonen)]

Per Emilio on Matrix, we don't make the requestAnimationFrame guarantee that this test expects a guaranteed that we don't make. We already have non-Fission expectation annotations for this test, and the Fission annotations are just a matter of Fission perturbing the timing of the non-guarantee.

Neha, I think it doesn't make sense to treat this as a Fission bug. Is it OK to stop tracking this for Fission?

https://wpt.fyi/results/html/interaction/focus/the-autofocus-attribute/first-when-later-but-before.html?label=master&label=experimental&aligned&q=focus%2Fthe-autofocus-attribute%2Ffirst-when-later-but-before.html shows Safari passing the test, but it also shows us passing the test.

Comment 12

[Henri Sivonen (:hsivonen)]

Looks like the test is legitimate per spec:
https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Yeah seems like we should move the autofocus code to somewhere after flushing in nsRefreshDriver::Tick or such.

Comment 14

[Neha Kochar [:neha]]

Untracking for Fission per comment 11.

Comment 15

[Chris Peterson [:cpeterson]]

Removing "with Fission" because this test failure is not Fission-specific.

Comment 16

[Chris Peterson [:cpeterson]]

Unblocking WPT-Fis meta bug 1586790 because this test failure is not Fission-specific.