Bugzilla

There's another issue showing up in test-verify where the pointerlock test is failing a fullscreen request with `FullscreenDeniedNotFocusedTab`. This is happening because the window occlusion is out-of-sync when the fullscreen request arrives. The fixes in Bug 1826645 made overlapping fullscreen requests work better by ensuring that a new request is held up while processing the old one, but there's apparently still a timing window where the request is done but the `OcclusionStateChanged` event hasn't been sent yet. In that case, a new request will reject with `FullscreenDeniedNotFocusedTab`. I do not have a good solution to this. I'm going to hand-wave those intermittencies away when requesting this landing.

Truly, we still have really challenging timing issues in our tests that use fullscreen. When fullscreen is async, we have at least these problems:
1) The one mentioned earlier in this comment, that a new request may be made after the previous request is finished but before the occlusion state is updated. It will error in such a case.
2) Orientation locks will fail until the occlusion state is updated, as noted in Bug 1830143 and worked around by the text expectation changes in D176573.
3) Pointer lock requests will fail until the occlusion state is updated, as worked around by the changes in D177200.
4) Whatever is going on with `browser_fullscreen_window_open.js` which fails sometimes even with synchronous fullscreen transitions.

The real fix for all of this would be to make a testing-harness-only signal that is sent after the occlusion state is updated, such that fullscreen and other APIs that require updated occlusion state (orientation lock, pointer locks, possibly others) could wait on it after a fullscreen transition. That's beyond the scope of what I want to do in this Bug.

There's another issue showing up in test-verify where the pointerlock test is failing a fullscreen request with `FullscreenDeniedNotFocusedTab`. This is happening because the window occlusion is out-of-sync when the fullscreen request arrives. The fixes in Bug 1826645 made overlapping fullscreen requests work better by ensuring that a new request is held up while processing the old one, but there's apparently still a timing window where the request is done but the `OcclusionStateChanged` event hasn't been sent yet. In that case, a new request will reject with `FullscreenDeniedNotFocusedTab`. I do not have a good solution to this. I'm going to hand-wave those intermittencies away when requesting this landing.

Truly, we still have really challenging timing issues in our tests that use fullscreen. When fullscreen is async, we have at least these problems:
1) The one mentioned earlier in this comment, that a new request may be made after the previous request is finished but before the occlusion state is updated. It will error in such a case.
2) Orientation locks will fail until the occlusion state is updated, as noted in Bug 1830143 and worked around by the test expectation changes in D176573.
3) Pointer lock requests will fail until the occlusion state is updated, as worked around by the changes in D177200.
4) Whatever is going on with `browser_fullscreen_window_open.js` which fails sometimes even with synchronous fullscreen transitions.

The real fix for all of this would be to make a testing-harness-only signal that is sent after the occlusion state is updated, such that fullscreen and other APIs that require updated occlusion state (orientation lock, pointer locks, possibly others) could wait on it after a fullscreen transition. That's beyond the scope of what I want to do in this Bug.