[whatwg] Fullscreen feedback

[Ian Hickson]

(This e-mail only contains responses to the one brief part of the full- 
screen API feedback that apply to the spec(s) I'm working on; I believe 
Anne has stated an intent to specify an API for actually supporting 
fullscreen display of Web content and I have not responded to feedback 
that would be appropriate for that spec. In case it is helpful to Anne, 
I've included below the feedback to which I did not include responses.)

On Fri, 20 Aug 2010, Mike Wilcox wrote:
> On Aug 20, 2010, at 3:24 PM, Ian Hickson wrote:
> > By CSSOM, I mean a separate specification, specifically one from the 
> > family of specifications that Anne is working on ...though my 
> > understanding is that Anne doesn't have the bandwidth to take this on 
> > right now (this may be less of a problem if Robert's proposal can just 
> > be taken wholesale, though).
> 
> RE: Fullscreen - I would be happy if the warning text was removed: User 
> agents should not provide a public API to cause videos to be shown 
> full-screen.

It appears the warning is no longer present. Did I just miss it?


The other feedback was as follows (trimmed to remove non-material 
feedback, process discussion, and redundant quoting):

On Fri, 20 Aug 2010, Adam Barth wrote:
> On Fri, Aug 20, 2010 at 7:25 PM, Robert O'Callahan 
> <robert at ocallahan.org> wrote:
> > On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson <ian at hixie.ch> wrote:
> >> One comment: Rather than adding an "allowfullscreen" attribute on 
> >> <iframe>, I would suggest just assuing that sandboxed content (i.e. 
> >> content of iframes with the sandbox="" attribute) can't go 
> >> fullscreen. I can provide a sandbox flag for this state. If we think 
> >> there are use cases for allowing sandboxed iframes to go fullscreen, 
> >> then I can also add a keyword that turns off the flag when present 
> >> (like "allow-scripts" does for scripts). (I'm assuming there are no 
> >> cases for disabling fullscreen for unsandboxed iframes; are there?)
> >
> > What about legacy content that doesn't use "sandbox"? It might expect 
> > cross-origin IFRAMEs to not be able to take over its window, but if 
> > the IFRAME content goes fullscreen, it effectively can.
> >
> > I think allowing subframes to go fullscreen should always be opt-in.
> 
> How is going fullscreen different from opening a popup window?

On Sat, 21 Aug 2010, Kit Grose wrote:
> 
> It's the same document *in the same state* as it was in when you 
> triggered "fullscreen". You would expect fullscreen on a video or 
> animation not to start that video or animation from the beginning or 
> reload it.

On Fri, 20 Aug 2010, Adam Barth wrote:
>
> I meant from a security model perspective.  :)

On Sat, 21 Aug 2010, Robert O'Callahan wrote:
> 
> That depends on how the UA chooses to handle it. But this proposed 
> fullscreen API is based on the idea that the fullscreen content "takes 
> over" the toplevel browsing context to which it belongs. (The content is 
> styled to fill the IFRAME, and the IFRAME element is styled to fill the 
> parent document's viewport.)

On Sun, 22 Aug 2010, Adam Barth wrote:
> On Sun, Aug 22, 2010 at 8:00 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> > On Sun, Aug 22, 2010 at 4:12 AM, Adam Barth <w3c at adambarth.com> wrote:
> >>
> >> That does seem dangerous if the location bar still displays the URL 
> >> of the top-level browsing context because it violates the constraint 
> >> principle of display delegation.
> >
> > That's why I want to default to prohibiting subframe content from 
> > going fullscreen.
> 
> Yeah, I agree that we'd need something like that in this model.  It's 
> unfortunate though.  Won't folks package <video> widgets using iframes?  
> I guess they'll need to include this silly attribute in their 
> "copy-and-paste this markup" code in order for full screen to work.
> 
> >> This doesn't seem like a good model for full-screen.  I would think 
> >> the model of re-parenting the content to a popup window that fills 
> >> the entire screen would be a better model.
> >
> > I think that model is a lot harder to spec and a lot harder for Web 
> > authors to understand. I'd certainly be interested in looking at a 
> > proposal if someone wants to pursue that approach.
> 
> There's been some work in WebKit around the concept of a "magic iframe" 
> that keeps it's environment intact even when it's adopted from one 
> document to another.  I'm not sure how much of that has been discussed 
> for standardization, but you could imagine a model like that working 
> where a frame is adopted into a "popup" window that fills the screen.

On Mon, 23 Aug 2010, Robert O'Callahan wrote:
> 
> That's sorta-ok if your video is a subframe that you treat as a black 
> box. But if your video element is just an element in your page with 
> event handlers attached to it, and with various scripts that interact 
> with it, and you rip that element out (plus maybe some supporting 
> elements representing your player UI) and drop it in another document, 
> it seems to me you're going to have to code very carefully to ensure it 
> keeps working over there (and the original page doesn't get into a bad 
> state). If there's confirmation UI so that the movement between 
> documents happens asynchronously, it's even more exciting. Moving the 
> element back when the user exits fullscreen has similar issues.
> 
> Maybe there are ways to make that model easy and convenient for authors. 
> I'd like to see a proposal.

On Sun, 22 Aug 2010, Adam Barth wrote:
> 
> Oh, I think the iframe-at-a-time is an easier model to work with since 
> the scripting context will get adopted into the full-screen view 
> together with the elements.

On Mon, 23 Aug 2010, Robert O'Callahan wrote:
> 
> It requires the author to put each part of their page that they want to 
> go fullscreen into its own subframe. That is cumbersome. With my 
> proposal, most existing pages and player UIs would work if you just call 
> "element.requestFullScreen()" in some event handler.

On Sun, 22 Aug 2010, Adam Barth wrote:
> 
> But it doesn't go full screen, right?  Didn't you say above that the 
> location bar is still there?

On Mon, 23 Aug 2010, Robert O'Callahan wrote:
>
> That depends on the UA. Assuming we implement this API using our 
> existing fullscreen functionality, in Firefox the element would be 
> fullscreen, but if the user moves the mouse to the very top of the 
> screen some browser chrome will pop down temporarily, including the URL 
> bar.

On Sun, 22 Aug 2010, Adam Barth wrote:
>
> So...  The trade-off is:
> 
> 1) Only browsing contexts can go full-screen (since they have URLs that 
> we could display).
>
> 2) Any element can go full-screen, but we'll need to add a nasty 
> non-semantic attribute.

On Mon, 23 Aug 2010, Robert O'Callahan wrote:
> 
> Is "allowfullscreen" really less semantic than "sandbox"?
> 
> Actually one option here is to only allow sandboxed iframes to go 
> fullscreen, deny fullscreen to sandboxed iframes by default, and provide 
> a sandbox token (e.g. "allow-fullscreen") that allows fullscreen. So you 
> could add sandbox="allow-scripts allow-fullscreen" to a video embedding 
> IFRAME.

On Sun, 22 Aug 2010, Adam Barth wrote:
> 
> Another idea is that we could let any element go full-screen, but then 
> we'd show the URL of its browsing context.  There's some subtleties here 
> about overlays from parent frames, but those seem solvable.

On Mon, 23 Aug 2010, Robert O'Callahan wrote:
>
> Doable, but maybe painful to implement, and there are numerous spec and 
> UI issues to do with navigation, history, etc.

On Tue, 21 Sep 2010, Shiv Kumar wrote:
>
> Pardon me if I've missed something. The last time I found and read the 
> spec on this feature it said that UAs should not provide a script 
> interface to put the video element in full screen.
> 
> Now in order for anyone to be able to provide their own skin/player, 
> we'll need to provide a scriptable way to switch the video element to 
> full screen and out including events to support the same.
> 
> I know the Webkit folks have provided, 
> webkitEnterFullScreen/webkitExitFullScreen methods to allow this. I 
> don't believe there are any events supporting the change in state.
> 
> I think it's important that the video element provide a scriptable way 
> to do this. Internally, the UA can determine if the call was made using 
> a user gesture as I believe Webkit is doing.

On Wed, 22 Sep 2010, timeless wrote:
> 
> it is not ok to allow content authors to refuse to deliver content 
> unless they are "full screen".
> 
> having events which enable providers to hold users hostage is a bad 
> thing.
> 
> if i have two screens today and try to watch a youtube video "full 
> screen" (with flash), it tries to unfullscreen when my focus shifts to 
> the other screen.
> 
> this isn't proper. my system should not be held hostage to the whims of 
> providers..

On Wed, 22 Sep 2010, Nils Dagsson Moskopp wrote:
> 
> With a platform like The Web, one should expect every feature provided 
> to be misused.

On Wed, 22 Sep 2010, John Harding wrote:
>
> That's Flash's behavior, not YouTube's choice - we'd love to allow 
> fullscreen usage on one screen while focus is in another.  This is the 
> right way to do it, though - content can* *request changes to the 
> fullscreen state, but the User Agent is ultimately responsible for 
> granting or denying that request, or even changing arbitrarily later on.

On Wed, 22 Sep 2010, Alex Bishop wrote:
> 
> There have been previous discussions about allowing scripts to request 
> that arbitrary content (including video elements) fill the full screen.
> 
> Here's one proposal:
> 
> https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI

On Wed, 22 Sep 2010, Gregg Tavares (wrk) wrote:
> 
> Is this proposal not good enough? 
> https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI
> 
> It handles the case I think you want. I also it's also useful for other 
> things like HTML5 games. It's also secure or at least as secure as 
> flash. The browser will not go fullscreen without either a prompt or a 
> mouse click.

On Thu, 23 Sep 2010, Mikko Rantalainen wrote:
> 
> I think that the Gecko Fullscreen API proposal is pretty good. I'd only
> change
> 	void requestFullScreen(unsigned short flags)
> to
> 	void requestFullScreen(unsigned short flags, function callback)
> 
> where callback function will be asynchronously called with true or false 
> once the UA has completed the request (true meaning the request was 
> accepted, false meaning that request was declined). In addition, the 
> proposal should probably suggest that request should be automatically 
> declined in case a new identical request is raised immediately after 
> declining previous request (denial of service attack).

On Fri, 24 Sep 2010, Robert O'Callahan wrote:
> 
> In fact, there has been a lot of clear feedback that an API that only 
> works on video elements is unlikely to get much use, since major video 
> sites very strongly prefer to use their own player UI in fullscreen 
> mode. And of course their own player UI consists of non-video 
> elements...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'