Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Tue, 18 Oct 2011 10:33:42 +0900, Anne van Kesteren ann...@opera.com wrote: Site A embeds site B. Site A goes fullscreen. Site B does requestFullscreen(). Site B does exitFullscreen(). Site A is no longer fullscreen. Either we need to base fullscreen on browsing contexts rather than top-level browsing contexts (how?) or give up on this use case. On IRC we discussed a solution to this model. Basically a document in which requestFullscreen() was invoked would have a flag set, so descendant documents could invoke requestFullscreen() and when exitFullscreen() on such a descendant document was invoked it would stop displaying ancestor (and any descendant) documents in fullscreen up until the first one that has the flag set. In addition there would be a fullscreen element and an original fullscreen element for each document so when exitFullscreen() is invoked you can reset the fullscreen element appropriately. However, I just realized this does not work for the single document case. You have a video player website and you host your videos in video or maybe a div container. So your video player website is displayed fullscreen, because your users like the fullscreen application feel from their OS, but then they click to display one of those videos fullscreen and once they hit exit the video player website is also no longer displayed fullscreen. Anyone any ideas? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Tue, Oct 18, 2011 at 3:55 AM, Anne van Kesteren ann...@opera.com wrote: However, I just realized this does not work for the single document case. You have a video player website and you host your videos in video or maybe a div container. So your video player website is displayed fullscreen, because your users like the fullscreen application feel from their OS, but then they click to display one of those videos fullscreen and once they hit exit the video player website is also no longer displayed fullscreen. Do you mean the user-fullscreen mode that most browsers enter with F11? That's a separate piece of state entirely, since it affects the whole browser window, not individual tabs. (You should still be able to enterFullscreen and exitFullscreen, to set and clear the fullscreen element. It just wouldn't change the browser window's actual fullscreen status.) -- Glenn Maynard
Re: [whatwg] Another bug in the HTML parsing spec?
On 10/17/11 5:47 PM, Ian Hickson wrote: On Mon, 17 Oct 2011, David Flanagan wrote: In the HTML spec, The rules for parsing tokens in foreign content include an algorithm for any other end tag. This is the algorithm at the very end of http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html. I think there are some problems with this algorithm and would appreciate any insight anyone has: 1) Step 3 includes an instruction to jump to the last step in the list of steps. But the last step begins Otherwise, which sounds like it is an else clause. Jumping into an else clause is confusing enough that I wonder if there is an error in the algorithm wording. Yeah, that's bogus. The last step it's referring to has been removed (it used to reset the insertion mode). I've fixed the spec. Thanks. With that change, my problem #3 below goes away, as you suspected. 2) I can't get all of the parser tests from html5lib to pass with this algorithm as it is currently written. In particular, there are 5 tests in testdata/tree-construction/tests9.dat of this basic form: !DOCTYPE htmlbodytablemathmifoo/mi/math/table As the spec is written, themi tag is a text integration point, so the foo text token is handled like regular content, not like foreign content. Oh, my, yeah, that's all kinds of wrong. The text node should be handled as if it was in the in body mode, not as if it was in table. I'll have to study this closer. I think this broke when we moved away from using an insertion mode for foreign content. Here's my current workaround: In 13.2.5, in the rules for whether to use the current insertion mode or to insert the token as foreign content, if the token is being inserted because the current node is a math (or HTML, but I'm not sure about that) integration point, then first set a text_integration_mode flag, then invoke the current insertion mode, then clear the flag. And in the in table insertion mode, when a character token is inserted, and the text_integration_mode flag is set, then just process the token using in body mode, and otherwise follow the directions that are there now. I'm not sure that is the best way to fix the spec, but it works for me, in the sense that my parser now passes the tests. David Henri, do you know how Gecko gets this right currently? The workaround I've found (I'm not confident that this is the correct workaround) is to change step 3 of the algorithm so that it only pops the stack if there is no pending table text. Another potential workaround is to use the existence of pending table text as a condition for sending tokens to the regular insertion mode rather than treating them as foreign content. We shouldn't be ending up with pending table text here at all. It should go straight into the mi element. 3) In this set of tests http://code.google.com/p/html5lib/source/browse/testdata/tree-construction/webkit01.dat there is this test: mathmrowmrowmn1/mn/mrowmia/mi/mrow/math When the first/mrow tag is parsed, it is handled as foreign content, and gets popped off the stack in step 3. Then, the token is reprocessed in body mode. It is treated in the any other end tag case. Since the top of the stack happens to be another mrow tag, that one gets popped too. (Other tests don't fail here because they don't happen to have two of the same tags on the stack). This means that themi element ends up as a child of themath element instead of the outermrow element. That should be fixed with the updated spec text now, right?
Re: [whatwg] How should overflow be handled when parsing integers?
On Oct 16, 2011, at 11:02 AM, Mounir Lamouri wrote: On 10/16/2011 02:17 PM, Daniel Bates wrote: How should overflow be handled when parsing integers? Step 8 of the parsing algorithm in bothhttp://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers andhttp://dev.w3.org/html5/spec/Overview.html#non-negative-integers doesn't mention how to handle integer overflow when interpreting the result of a sequence of base-ten integers. Currently in WebKit we consider such overflow a parsing error. Is there any reason not to consider overflow a parsing error? Regardless, I suggest codifying the handling of overflow in the aforementioned sections. Gecko also considers that an overflow is a parsing error. Presto and IE6 doesn't seem to. The specs should probably mention this by whether consider it as a parsing error or request the UA to default to the highest value (which Presto and IE6 seem to do but not using the same value). Notice that spec tends to provide guidance when the rules for parsing a number return an error. For instance, the spec defines what happens when parsing the value of the tabindex attribute returns an error: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#sequential-focus-navigation-and-the-tabindex-attribute. I suggest that we return an error in step 8 of the rules for parsing signed/non-negative integers when the sequence of characters cannot be interpreted as an base-ten integer that is representable using an integer datatype. Then we can leave it up to the relevant sections of the spec to define how to handle such a parser error (like in the case for tabindex), including whether to fall back to an agreed default value or leave it up to the UA (which may default to the highest value). This issue came up recently in WebKit with respect to the parsing of the maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981). Actually, this problem wouldn't have been that annoying if Webkit was following the specs regarding maxlength attribute: if the content attribute value isn't a valid non-negative integer, the element has no maximum allowed value length. Thank you for bringing this up and directly commenting about this on the bug (https://bugs.webkit.org/show_bug.cgi?id=68981). Currently WebKit doesn't conform to this behavior. As mentioned by Kent Tamura on the bug, this issue is covered by WebKit bug #44883 (https://bugs.webkit.org/show_bug.cgi?id=44883). Dan
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Tue, Oct 18, 2011 at 7:24 AM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 18, 2011 at 3:55 AM, Anne van Kesteren ann...@opera.com wrote: However, I just realized this does not work for the single document case. You have a video player website and you host your videos in video or maybe a div container. So your video player website is displayed fullscreen, because your users like the fullscreen application feel from their OS, but then they click to display one of those videos fullscreen and once they hit exit the video player website is also no longer displayed fullscreen. Do you mean the user-fullscreen mode that most browsers enter with F11? That's a separate piece of state entirely, since it affects the whole browser window, not individual tabs. (You should still be able to enterFullscreen and exitFullscreen, to set and clear the fullscreen element. It just wouldn't change the browser window's actual fullscreen status.) In Chrome, the user-fullscreen mode you get when you press F11 places the active tab into fullscreen mode. It is interesting to wonder how this API should interact with user-fullscreen mode. However, maybe that is best left to the UAs and shouldn't be covered by this spec. -Darin
Re: [whatwg] Fullscreen
On Mon, 17 Oct 2011, Chris Pearce wrote: On 15/10/2011 5:27 p.m., Anne van Kesteren wrote: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Defining when exactly the fullscreen enabled flag is set for Document objects I will leave up to HTML. As well as defining the allowfullscreen attribute. Presumably it should be set for Document objects associated with the top-level browsing context and descendant browsing context as long as their browsing context container has the aforementioned attribute set. By this do you mean the fullscreen enabled flag should be defined elsewhere in the HTML spec? Can we at least link to is to that it's easy for implementors to find? Ditto for allowfullscreen. Both of these things are important, we should have references to them at least. Or include them in this spec, with a note to move them into their new homes once we agree on the spec. I haven't yet added them to the spec. I'm sure Anne will add links once I have. :-) Anne, is there a bug or e-mail tracking what exactly you'd like me to add to the HTML spec here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Mon, 17 Oct 2011, Darin Fisher wrote: On Mon, Oct 17, 2011 at 4:31 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 18 Oct 2011 08:11:41 +0900, Darin Fisher da...@chromium.org wrote: OK, I can't help myself. One more question: What should happen if the fullscreen browsing context is navigated? What happens if the document, containing the fullscreen element, is destroyed? Perhaps it should bounce out of fullscreen mode? The current plan is that if any of the browsing contexts with non-null fullscreen element is navigated you exit fullscreen. I agree. That's the only sane behavior. I'm going to implement that behavior for Chrome. Presumably this should happen after the step in the navigation algorithm where it is established that we are going to another document (i.e. not just for #fragment navigations). Should it happen before or after onbeforeunload and onunload? Should it just happen when the session history is updated (i.e. when the page load changes the rendering), or at some other point? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Tue, 18 Oct 2011 23:24:27 +0900, Glenn Maynard gl...@zewt.org wrote: Do you mean the user-fullscreen mode that most browsers enter with F11? Not necessarily. You run into the same issue with requestFullscreen() usage. That's a separate piece of state entirely, since it affects the whole browser window, not individual tabs. (You should still be able to enterFullscreen and exitFullscreen, to set and clear the fullscreen element. It just wouldn't change the browser window's actual fullscreen status.) I think it would be kind of nice if the UI and API-based fullscreen were aligned. Otherwise you run into all kinds of odd situations. E.g. API-based fullscreen first. Then via native video controls you go UI-based fullscreen for a video displayed on that page. What happens when you exit? You can have the same scenario the other way around, or both can be done using solely the UI, or both can be done using solely the API. It would be confusing to users I think if you got different results here. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]
On Tue, Oct 18, 2011 at 9:23 PM, Anne van Kesteren ann...@opera.com wrote: I think it would be kind of nice if the UI and API-based fullscreen were aligned. Otherwise you run into all kinds of odd situations. E.g. API-based fullscreen first. Then via native video controls you go UI-based fullscreen for a video displayed on that page. What happens when you exit? You can have the same scenario the other way around, or both can be done using solely the UI, or both can be done using solely the API. It would be confusing to users I think if you got different results here. It'd be nice if native video fullscreen buttons could be implemented using the fullscreen API directly. A really nice side-effect would be that scripted video controls could behave exactly the same as native controls (possibly excluding permission checks), including document.fullscreenElement and the fullscreenchanged event. It seems like it would need fullscreenElement to be a stack, though, so exitFullscreen can drop back into the previous fullscreen state. -- Glenn Maynard
[whatwg] Fullscreen Update
1) How much should UI-based and API-based fullscreen interact? To me it seems nice if pressing F11 would also give you fullscreenchange events and that Document.fullscreen would yield true. Why would you not want to give the same presentation via native activation and API-based activation? Of course when you activate it UI-wise, navigation should not exit it. For native video controls the case seems clearer that they should work using this API. 2) Chris brought forward the case of nesting. You have a fullscreen presentation (lets assume API-based activated for now) and in that presentation there's some video that the presenter wants to display fullscreen (lets assume the video player is a custom widget with API-based fullscreen activation for now). Once the presenter exits displaying the video fullscreen, the presentation should still be fullscreen. Initially this was brought up with the video being hosted in a separate descendant document, but the video could be in the same document as well. roc suggested a model that works when you have separate documents and it could be made to work for the single document case too, as long as the level of nesting remains is no larger than required for the presentation scenario mentioned above. Is that an acceptable limitation? Alternatively we could postpone the nested fullscreen scenario for now (i.e. make requestFullscreen fail if already fullscreen). -- Anne van Kesteren http://annevankesteren.nl/
