requestFullscreen() + moving pending element can fire fullscreenerror but leave browser in fullscreen

[foolip]

As noted by @upsuper in https://github.com/whatwg/fullscreen/pull/87#issuecomment-301746317:

when this happens, the browser window would end up being in fullscreen state while the content is not?

A test which could be adapted to cover this is https://github.com/w3c/web-platform-tests/blob/5e1a3b80cea8d36774d2afd78b29a74792e9f15a/fullscreen/api/element-request-fullscreen-and-move-to-iframe-manual.html

Invoking "exit fullscreen" wouldn't be enough to recover, because it is a no-op when there is no fullscreen element. Rather, 'resize something's viewport to its "normal" dimensions' would be needed.

[foolip]

Continuing from https://github.com/whatwg/fullscreen/pull/87#issuecomment-301755115

Does that "revert the window state" appear as a step of one of the spec algorithms, or is it something that happens after the spec algorithms have run, to revert if nothing ended up in fullscreen?

[upsuper]

That actually is "resize topLevelDoc’s viewport to its 'normal' dimensions" from "exit fullscreen".

Actually, it seems to me we need a "resize" variable in requestFullscreen algorithm as well, and do the resizing only when that is true, and we can call "resize ... to its 'normal' dimensions" when error happens in the "next animation frame task" and resize is true.

[foolip]

Do you mean that you're using "exit fullscreen" internally here? Isn't it a no-op when there's no fullscreen element?

https://github.com/whatwg/fullscreen/pull/64 was about synchronously deciding whether to resize in requestFullscreen, but I've since made other conflicting changes. I'll try rebasing it to see if what remains is useful.

[foolip]

I've rebased https://github.com/whatwg/fullscreen/pull/64 and as it turns out I had added steps to handle this situation.