fullscreen
fullscreen copied to clipboard
whatwg
Re-introduce the hierarchy restrictions
The hierarchy restrictions were removed in 766dc872bcf26c012549f7bdfde21c46bebba40c and 9592913bbeca3a9d029274f310eb27ad8003622c because it seemed to be unnecessary after we moved to the top layer model.
However, it forms an unfortunate combination with the change to make fullscreenchange event dispatched to element, that if we have multiple leaf fullscreen element in the stack, some of the element wouldn't get the fullscreenchange event. I raised in #89 (comment), and @foolip said he's fine adding back these restrictions in #89 (comment) and opened #91 to do so.
Recently, #91 was abandoned probably because of lack of activity and people don't recall the reasoning to do so. So I'm opening this issue to track that.
Blink currently doesn't have the hierarchy restrictions, while Gecko still has. And if we decide to re-introduce it, Blink may want to change before it's too late.
cc @dtapuska
These manual tests are checking against hierarchy restrictions:
- fullscreen/api/element-ready-check-fullscreen-element-sibling-manual.html
- fullscreen/api/element-request-fullscreen-non-top-manual.html
- fullscreen/api/element-request-fullscreen-two-elements-manual.html
Adding back the hierachy restrictions for this event targetting is unforunate. We are forcing users into a model of how to design their application that the content must be present in the child of the current fullscreen element.Think of a series of divs that are all siblings and you click 'next'. Which would change the fullscreen element to the next element. In order to replicate that you'd need to do a bunch of tree modifications. Also it prevents you from re-entering a fullscreen element already on the stack.
@domenic Adding Domenic in case he has any ideas here.
Think of a series of divs that are all siblings and you click 'next'. Which would change the fullscreen element to the next element.
That is not a usecase that the current Fullscreen API is supposed to support. You would end up having lots of elements in the fullscreen layer, and you cannot exit fullscreen in one statement (unless we add #70).
If we want to serve this usecase, we may want an API like requestFullscreen({ replace: true }) or so, rather than supporting multi-leaf.