Xidorn Quan

It is not a spec bug, because the spec doesn't even have the behavior of viewport scrollbar specified at all. The fullscreen element being `position: fixed !important` is fine, because...

If it is really desired to have viewport scrollbar available for ``, I suggest the spec say something like, if the `fullscreenElement` is not null, and it is not the...

Effectively, yes. But I don't think we should bring back the removed `:fullscreen-ancestor` pseudo-class only for this. `:fullscreen-ancestor` would be less efficient to maintain if we do not restrict what...

Actually, one difference I just found. If you have, say, `overflow: scroll;` on ``, and the default `overflow: visible` for `:root`, when you request fullscreen on `document.body`, whether the scrollbars...

The solution is: don't request fullscreen on root element.

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 first obstacle was that `playerElementInIframe.requestFullscreen()` can't be called cross-site via postMessage from the website that embeds the player because it requires a short running task from a user...

Ha... I proposed something similar for Firefox in the past, but wasn't accepted... But yeah, if it becomes a time-based model, it's probably dangerous to allow it go across the...

Filed [bug 1329052](https://bugzilla.mozilla.org/show_bug.cgi?id=1329052) for Gecko.

No. In that case, `resize` is `false`, so it won't fully exit fullscreen in that step.