1959973 - neversleep.me - Focusing in another window and returning to the page tab keeps the page is a disabled red state

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 136.0

Steps to reproduce:

1. Navigate to: https://neversleep.me
2. Open a new tab
3. Return to the previous page and observe

Expected Behavior:
The page is in a green state

Actual Behavior:
The page is in a red state

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/149903

Comment 1

[Raul Bucata]

Attachment: chr vs ff.mp4

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Sky Schubert [:skyschub]]

The color change happens inside a focus listener on the document. Not exactly sure what this site is supposed to do, but let's assume it's broken.

Comment 4

[Sean Feng [:sefeng211]]

                  return n() ? navigator.wakeLock.request('screen').then(
                    function (e) {
                      A._wakeLock = e,
                      A.enabled = !0,
                      document.dispatchEvent(new CustomEvent('focus', {
                        detail: 'in'
                      })),
                      A._wakeLock.addEventListener(
                        'release',
                        function () {
                          document.dispatchEvent(new CustomEvent('focus', {
                            detail: 'out'
                          }))
                        }
                      )
                    }

The site uses the wake lock API to dispatch custom focus events. Looks like release is called when it shouldn't?

Vincent, thoughts about this?

Comment 5

[Vincent Hilla [:vhilla]]

I think the problem is that we fire a native focus event on the document when the user comes back to the tab.

:sefeng you are more familiar with focus handling, right?

---

app.js:

document.addEventListener("focus", function(e) {
	if (e.detail === "in") {
		document.title = "NeverSleep Enabled";
		document.body.style.backgroundColor = 'rgb(193, 221, 199)';
	} else {
		document.body.style.backgroundColor = 'red';
		document.title = "NeverSleep Disabled";
	}
});

By observing document.addEventListener("focus", console.log) on the page, I see two issues:

1. When the window is visible but not focused, the wake lock won't be released. But when the user returns, a native focus event is fired and above else clause is executed.
2. When quickly switching between tabs, the native and custom focus events appear to be racy, with the native coming after the custom event. If I switch between tabs like in the video but slowly, the page doesn't stay red.

Comment 6

[Sean Feng [:sefeng211]]

Thanks, Yeah that makes sense.

Looks like we are the only that fires a focus event to the document, Webkit/Blink don't do it, though we all would fire a focus event to the window.

This also looks like an very old behaviour. I am also not sure what the spec says for this case.

Simon, I didn't find anything relative in the spec, do you know by chance?

Comment 7

[Simon Pieters [:zcorpan]]

Searching for "event named focus" finds the relevant spec text:

https://html.spec.whatwg.org/#focus-update-steps says

If entry is a Document object, let focus event target be that Document object's relevant global object.

(relevant global object is the Window object)

let related focus target be null.

If focus event target is not null, fire a focus event named focus at focus event target, with related focus target as the related target.

To fire a focus event named e at an element t with a given related target r, fire an event named e at t, using FocusEvent, with the relatedTarget attribute initialized to r, the view attribute initialized to t's node document's relevant global object, and the composed flag set.

Comment 8

[Sean Feng [:sefeng211]]

Thanks, look like we are the one that isn't following the spec

Comment 9

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

Asking for re-prioritization. Per the diagnosis findings, "Notable annoyance" should be the right case, instead of site-broken.
(Vincent, please free feel to chime in, in case I got it wrong.)

Comment 10

[Vincent Hilla [:vhilla]]

Right.

To be precise, the functionality to request a wake lock whenever possible to keep the device from sleeping works as intended. But the visual indicator, i.e. the red or green background, is broken.

Comment 11

[Sean Feng [:sefeng211]]

Clear my NI given I won't be able to work on this

Comment 12

[Vincent Hilla [:vhilla]]

Removing the focus event for document works well with WPT, but breaks many mochitests: https://treeherder.mozilla.org/jobs?repo=try&revision=56e78a55fb0344f543ca3daa33b58ce63be26770

Comment 13

[Vincent Hilla [:vhilla]]

Many might come from

• SimpleTest.promiseFocus waiting for the focus event on the document instead of window: https://searchfox.org/mozilla-central/rev/387160feb07b75ae76bfc12df035a10f58d25168/testing/mochitest/tests/SimpleTest/SimpleTest.js#1021
• SpecialPowers.ensureFocus does the same: https://searchfox.org/mozilla-central/rev/387160feb07b75ae76bfc12df035a10f58d25168/testing/specialpowers/content/SpecialPowersChild.sys.mjs#289