User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Tested on 2 different computers in normal mode and in safe/troubleshooting mode, and on a VM with a fresh Fx install, all behave the same:

Play an embedded youtube video, then either A. enter or exit fullscreen (by double click or button in the bottom right corner), or B. enter and exit (with f key).

Actual results:

Keyboard shortcuts (like F, spacebar, left, up) don't work anymore. (Only Esc still works.) Only after clicking the video (this pauses the video; you can leave it paused or click-unpause, this doesn't affect the behaviour) do they work again.

Expected results:

Keyboard shortcuts should still work.

A recent Fx update broke this functionality, up until a few weeks ago this still worked properly.

Tested with some Firefox portables.

v110.0: same bug
v106.0: working properly

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

(In reply to G from comment #0)

A recent Fx update broke this functionality, up until a few weeks ago this still worked properly.

Could you run mozregression to see exactly when this started happening?

A number of Firefox versions will open in succession to narrow down when this started occurring. Simply answer "good" or "bad" based on whether or not a build reproduces the bug. Once finished, please post the output from the last run. It should give a last good and first bad revision as well as a link to look at the changesets in that range. Thank you!

I ran the thing and think I'm supposed to post this:

"Bug 1740989 - Implement focus fixup rule. r=smaug

This implements the proposal in the linked spec issue, and makes
it nightly-only pending resolution + edits."

Just to be sure, here are the 7 last tests:
https://i.imgur.com/e1rcIWx.png

build 9b193eea 2022-09-01 11:53:05.598000 is still good
build 81580b85 2022-09-01 12:09:07.038000 is bad

(In reply to G from comment #4)

I ran the thing and think I'm supposed to post this:

Yup, that was it. Flagging as regression and pinging the author. Thanks!

The following field has been copied from a duplicate bug:

For more information, please visit auto_nag documentation.

Set release status flags based on info from the regressing bug 1740989

Okay so I dug into this and the issue is that when we enter fullscreen we reframe the top-level <browser> element. When that happens, there's a moment in time during the reframe where we set the hidden under embedder element flag, and even tho we unset it rather quickly, if we fix up the focus in the meantime we detect the element as not being focusable here.

So I believe we can probably hack around this, but the right fix is bug 1740989 (plus another change that I'll upload here).

If we reframe an OOP iframe, before this patch we send this message to
the content process, and it's not until we reframe that we set the flag
to false again.

Unfortunately, that means that there's a period in time where, if the
other process ticks, it'd find all elements as non-focusable, and we'll
fix up the focus, incorrectly potentially.

We could hack around in the focus code, but this (written on top of the
rebased bug 1750189), which properly detects whether we get reframed,
seems slightly nicer?

Depends on D138732

Feels wrong, so I'd rather not.

Set release status flags based on info from the regressing bug 1740989

Emilio, are there plans to land a fix this cycle? Thanks

It's 4 months and 5 versions later, is there any update on this? I encounter this bug nearly daily and it's quite frustrating.