1682685 - Intermittent html/interaction/focus/document-level-focus-apis/document-has-system-focus.html | Timeout

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I added a new WPT test upstream https://github.com/web-platform-tests/wpt/pull/26845 that tests document unfocus/refocus when opening/closing a popup. It passes in all browsers except firefox-nightly-stability where it times out intermittently: https://github.com/web-platform-tests/wpt/pull/26845/checks?check_run_id=1539846357

I was also able to repro locally (1 of 3 times on macOS) — need to pull down the 2 test files in the above PR until they're pulled in to mozilla-central upstream:

mach wpt --verify testing/web-platform/tests/html/interaction/focus/document-level-focus-apis/document-has-system-focus.html

 0:33.43 INFO ### /html/interaction/focus/document-level-focus-apis/document-has-system-focus.html ###
 0:33.43 INFO |                                                 Subtest                                                  |            Results            |     Messages     |
 0:33.43 INFO |----------------------------------------------------------------------------------------------------------|-------------------------------|------------------|
 0:33.43 INFO |                                                                                                          | **OK: 9/10, TIMEOUT: 1/10**   |                  |
 0:33.43 INFO | `Top-level document receives blur/focus events and loses system focus during opening/closing of a popup` | **PASS: 9/10, TIMEOUT: 1/10** | `Test timed out` |
 0:33.43 INFO 
 0:33.43 INFO ## Unstable results ##

 0:33.43 INFO |                                        Test                                        |                                                 Subtest                                                  |            Results            |     Messages     |
 0:33.43 INFO |------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------|-------------------------------|------------------|
 0:33.43 INFO | `/html/interaction/focus/document-level-focus-apis/document-has-system-focus.html` |                                                                                                          | **OK: 9/10, TIMEOUT: 1/10**   |                  |
 0:33.43 INFO | `/html/interaction/focus/document-level-focus-apis/document-has-system-focus.html` | `Top-level document receives blur/focus events and loses system focus during opening/closing of a popup` | **PASS: 9/10, TIMEOUT: 1/10** | `Test timed out` |
 0:33.43 INFO 
 0:33.43 INFO ::: Running tests in a loop 10 times : FAIL
 0:33.43 INFO :::
 0:33.43 ERROR ::: Test verification FAIL
 0:33.43 INFO :::

I don't see anything wrong with the test, and it passes in other browsers, so I think this may be a Firefox bug.

Comment 1

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-20)]

Possibly the same root cause as bug 1642889 but with a different native toolkit. I've also seen the test in bug 1642889 fail a couple of times on Mac.

The attempted workaround there isn't going so great so far. As for fixing this in Gecko, I'm worried about it breaking more than it would fix.

Neil, do you think it would be worthwhile to generate nsFocusManager::WindowLowered within Gecko for the previously-frontmost native window when we open a new one and then ignore the corresponding native toolkit notification?

Comment 2

[Neil Deakin]

WindowLowered is already called if WindowRaised is called first.

But if I'm reading the failure above correctly, this failure is happening when a window is closed?

Comment 3

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-20)]

I believe the problem is that WindowShown doesn't call WindowLowered the way WindowRaised does.

Comment 4

[Neil Deakin]

WindowShown is called when any document or child frame is first painted, to ensure that the focus is placed/updated in that frame correctly. I'm not clear why it would call WindowLowered. Perhaps the method name should be clearer to distinguish it from WindowRaised/Lowered which only get called on top-level windows.

I wasn't able to reproduce this problem myself unfortunately using the command above. I've not seen this type of issue on Mac, but it is common on Linux for the gtk window container focus events to get lost in certain situations when opening and closing windows rapidly during automated tests, but a good fix has not been found.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I'm no longer able to reproduce comment 0 on mac, so that may have been a fluke (maybe I accidentally clicked somewhere else). Anyways that 1/9 timeout is no match for the 6/10 timeouts seen on taskcluster, so it may be different. A linux problem as suggested in comment 4 might explain the taskcluster fails.

Comment 6

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-20)]

(In reply to Neil Deakin from comment #4)

I wasn't able to reproduce this problem myself unfortunately using the command above. I've not seen this type of issue on Mac, but it is common on Linux for the gtk window container focus events to get lost in certain situations when opening and closing windows rapidly during automated tests, but a good fix has not been found.

As noted in bug 1642889 comment 25, calling WindowLowered from WindowShown didn't work, because then the matching WindowRaised was missing. So it wasn't a matter of the native focus notification being late but the newly-opened window not being considered by Gtk to be in front of the older window at all.