This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I found there are several issues on interaction between fullscreen and <dialog>. If we have the following document: div id=a | +-div id=b | +-dialog id=c | +-div id=d Case #1: 1. request fullscreen on #b, 2. open modal dialog #c, 3. request fullscreen on #d. If I understand the specs correctly, in this case, the third step is a no-op. #d will not be made fullscreen because it is not a descendent of #b, which is the top element in the "fullscreen element stack". [1] But, if we change a little: Case #2: 1. request fullscreen on #a 2. open modal dialog #c, 3. request fullscreen on #d. This time, #d is successfully made fullscreen. I think it is an odd behavior, because authors should expect that #d is either (1) always open because its a descendent of the top element in the top layer stack, or (2) never open because a modal dialog is present. And what if we do this: Case #3: 1. open modal dialog #c 2. request fullscreen on #b If I read the specs correctly, it is the most unfortunate case. #b will be made fullscreen, because there was no element in the "fullscreen element stack" before, and cover the modal dialog, because it is added to the top layer stack later than #c, which makes it be closer to the user than the dialog. [2] However, according to the HTML spec, when there is any modal dialog opened, any element except the dialog and its descendent is marked inert, [3][4] which means although #b is the topmost element, it cannot receive any user interaction event before the invisible modal dialog get closed. [5] To solve these issues, I propose the following changes to the Fullscreen API spec: 1. Change the third and the last step of the "fullscreen element ready check" algorithm, make it check according to top layer stack instead of the "fullscreen element stack"; 2. Replace the "fullscreen element stack" with "fullscreen element set", and make all order depend on top layer stack only, so that we don't need to worry when their order is out of sync. [1] https://fullscreen.spec.whatwg.org/#fullscreen-element-ready-check [2] https://fullscreen.spec.whatwg.org/#new-stacking-layer [3] https://html.spec.whatwg.org/multipage/forms.html#dom-dialog-showmodal [4] https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-modal-dialog [5] https://html.spec.whatwg.org/multipage/interaction.html#inert
Making the Fullscreen API directly work upon a layout structure seems unfortunate.
Okay, it seems like we ought to get rid of the fullscreen element stack.
The problem description is pretty compelling, it sounds like some kind of change is indeed needed. The fullscreen element stack include iframes which have their own fullscreen element stacks and the style of all :fullscreen elements ensures that a deep fullscreen element still occupies the whole screen. Is there some kind of equivalent to this in top layer land? Currently if an iframe is in fullscreen, you can only descend further into that iframe, a sibling iframe can't become fullscreen. Is there any security or nuisance-avoidance aspect to this?
(In reply to Philip Jägenstedt from comment #3) > The problem description is pretty compelling, it sounds like some kind of > change is indeed needed. > > The fullscreen element stack include iframes which have their own fullscreen > element stacks and the style of all :fullscreen elements ensures that a deep > fullscreen element still occupies the whole screen. Is there some kind of > equivalent to this in top layer land? I don't see any problem for this case. We still need to keep track on what elements are made fullscreen. The only different thing is that we now use top layer stack instead of the fullscreen element stack for the order. > Currently if an iframe is in fullscreen, you can only descend further into > that iframe, a sibling iframe can't become fullscreen. Is there any security > or nuisance-avoidance aspect to this? I think it is by design. This looks conceptually more correct.
Continuing from IRC: http://krijnhoetmer.nl/irc-logs/whatwg/20150702#l-364 I think it sounds like a good idea to merge the two stacks, and it becomes a matter of keeping track which the elements in the top layer stack are there because of fullscreen calls. Previously one could only enter fullscreen for descendants (including via iframes) of the current fullscreen element. So the new cases to make sure are sane are: 1. You request fullscreen on an ancestor of the fullscreen element. Do nothing? 2. You request fullscreen on a sibling/uncle of the fullscreen element. Just make it work? 3. You request fullscreen on the current fullscreen element. You can already do this, but what should happen?
We also need to consider carefully about how this would affect nested documents in iframes. If we decide that fullscreen request is accepted according to top layer, we would also need to check the top layer stack of ancestor documents. (Sometimes I wonder life would probably be much easier if we get rid of the concept of top layer and just leave fullscreen how it is implemented currently. It seems to produce more problems than it solves.)
I think that if we do move to the top layer, then the checks in requestFullscreen() should also be relaxed to match, it wouldn't make sense to try to maintain exactly the current behavior. As for requests in iframes, is this really different from a non-iframes case? As long as the iframe element itself can be put into the top layer, which it presumably can, then wouldn't it work out?
(In reply to Philip Jägenstedt from comment #7) > As for requests in iframes, is this really different from a non-iframes > case? As long as the iframe element itself can be put into the top layer, > which it presumably can, then wouldn't it work out? It is really different. The problem is, we cannot move an element inside the iframe to the top of the stack without also puting the whole iframe there. For example: +-iframe | | | +-div id=a | | | +-div id=b | +-div id=c Then we call: 1. request fullscreen on #a, then 2. request fullscreen on #c, then 3. request fullscreen on #b What should happen? (It doesn't have anything weird with the current check algorithm, though, but what if it is relaxed to allow such calls?) The other difference is that we need to dispatch events to subdocuments when we exit fullscreen from the top. If we have a fullscreen document tree, we will also need to specify the order of events to dispatch. Which is doable, but just much more complicated than it currently is.
It seems like this is equivalent to the case where you have two siblings A and B, and request fullscreen in order A, B, A. Either the last request fails due to some check, or we can make it work by removing A from within the top layer stack and putting it on top again. Now make A an iframe and the problems looks the same, to me at least.
I haven't really addressed any of your questions, but I have refactored stack away in favor of just a top layer and a new fullscreen flag: https://github.com/whatwg/fullscreen/commit/0b7c994bfcedb291cb9ab7398b26cb4a575470d1
Reviewing this thread, it seems Xidorn and Philip should figure out what they can agree on and what changes they want to make. I don't really have a strong opinion here. Hopefully reviewing is easier now that the stack concept is gone.
https://github.com/whatwg/fullscreen/commit/766dc872bcf26c012549f7bdfde21c46bebba40c was the last commit needed here I think.