Add Document.webkitIsFullScreenEnabled property.
Created attachment 108698 [details] Patch
Comment on attachment 108698 [details] Patch Attachment 108698 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9843913
Created attachment 108707 [details] Patch Added missing entry from RuntimeEnabledFeatures.h
Comment on attachment 108707 [details] Patch This doesn't seem like a regular way to check for features at runtime. Is there a reason why a check like 'if ("webkitIsFullScreen" in document)' won't work? I'm sufficiently sure that this isn't the way to go to say r-, but I could be missing something.
I think the “enabled” concept here is more about whether the user has turned it off or something along those lines, not whether the engine has the capability.
(In reply to comment #5) > I think the “enabled” concept here is more about whether the user has turned it off or something along those lines, not whether the engine has the capability. Yes, this is right. It's a way to know in advance whether the browser will reject a full-screen request outright. If a user has checked a "never allow this" box, for example, this property would return false. I originally argued for this property to be called "fullScreenAllowed", but roc pointed out that there's no way to know in advance whether a given request will be allowed, or even acted upon. So "enabled" it is.
Another use case mentioned was that one browser vender is planning on disabling full screen "when a windowed plugin is present in the document."
I still don't see why 'if ("webkitIsFullScreen" in document)' wouldn't work. We don't expose other browser preferences like this, and it's unclear why fullscreen needs to be different. Is it because EnabledAtRuntime is only implemented for v8 at the moment, not yet for JSC (bug 52011)?
(In reply to comment #8) > I still don't see why 'if ("webkitIsFullScreen" in document)' wouldn't work. I think it might work, but to me it seems inelegant. Leaving something out entirely is a good way to reflect the fact that a feature doesn’t exist at all in a web engine; it’s a great way to be forward-compatible with new features. Leaving things out dynamically based on policies and user settings seems a little odd, and not a natural way to communicate policy to websites.
I have some additional considerations: - A better name could make this more palatable. Jer mentioned that this is not only about the feature being enabled in preferences, but about a browser prediction whether it's likely to honor the request (e.g. depending on page content). - It's not really clear why page authors would care about such browser prediction though. Developers test in major browsers to ensure that their site works; they are not commonly handling any error cases. There are many important implementation specific limitations in browsers (e.g. whether a page is stored in b/f cache), and we don't tell about those in advance. - Having a preference accessor does not match other related specs. E.g. Mouse Lock doesn't tell you whether it's going to succeed - instead, it reports after the fact. For a common case like full screen game, you really need both, so disabling parts of your own UI based on fullscreen prediction alone is insufficient. - We don't tell the page in advance whether we're going to block pop-ups or 3rd party cookies, why do we tell that about fullscreen? - I see your point about the difference between unimplemented features and ones that are enabled at runtime. A Web page may indeed want to have a different behavior in these cases (prompting the user to enable the feature), although it seems unlikely to be very common, especially long-term. I don't necessarily agree that it's unnatural - there is not that much difference for a Web page between a browser that doesn't support a feature and one that has it fully disabled at runtime, so detecting these with one test makes sense to me.
Also, if we expose a browser preference with the goal of letting pages change appearance or behavior based on it, then perhaps we also need a callback when it changes.
Shouldn't the Webkit API be webkitFullScreenEnabled? There's no "is" in the proposed attribute. Doesn't really matter given the prefixing, but may confuse authors later. (In reply to comment #10) > - A better name could make this more palatable. Jer mentioned that this is > not only about the feature being enabled in preferences, but about a browser > prediction whether it's likely to honor the request (e.g. depending on page > content). To clarify: when fullScreenEnabled returns false, the browser guarantees that a requestFullScreen made at that moment will be denied. When fullScreenEnabled returns true, no guarantees are made. Can you suggest a better name? > - It's not really clear why page authors would care about such browser prediction though. Developers test in major browsers to ensure that their site works; they are not commonly handling any error cases. There are many important implementation specific limitations in browsers (e.g. whether a page is stored in b/f cache), and we don't tell about those in advance. Youtube is requesting this feature, primarily so that a player in an <iframe> lacking the "allowfullscreen" attribute can alter its UI due to fullscreen being disabled. > - Having a preference accessor does not match other related specs. E.g. Mouse Lock doesn't tell you whether it's going to succeed - instead, it reports after the fact. For a common case like full screen game, you really need both, so disabling parts of your own UI based on fullscreen prediction alone is insufficient. Yes, we'll still be reporting after the fact as well. But I think it still make sense to remove a fullscreen button from your UI when you *know* it won't work. > - We don't tell the page in advance whether we're going to block pop-ups or 3rd party cookies, why do we tell that about fullscreen? Perhaps people have not asked for an API to detect whether cookies or pop-ups are enabled? The value of fullScreenEnabled can change dynamically, e.g. when a containing page adds or removes the "allowfullscreen" attribute of an <iframe>. I don't think dynamically adding or removing full-screen-related properties and/or methods from the document is appropriate.
I didn't know that this is also affected by an iframe attribute. Hiding fullscreen properties for feature detection is clearly inappropriate in that case. Presumably the reason why YouTube code cannot just check presence of the attribute on frame element is that the expected use case is cross origin, correct? Given that the result combines several entirely unrelated checks into an implementation specific policy, the "enabled" name seems extremely confusing, whether I personally have a better suggestion or not: - user preference; - iframe property; - presence of windowed plug-ins; - something more?
(In reply to comment #13) > Presumably the reason why YouTube code cannot just check presence of the attribute on frame element is that the expected use case is cross origin, correct? Correct. > Given that the result combines several entirely unrelated checks into an implementation specific policy, the "enabled" name seems extremely confusing, whether I personally have a better suggestion or not: > - user preference; > - iframe property; > - presence of windowed plug-ins; > - something more? The semantics are well-defined, and I think not confusing, as described in comment #12: "when fullScreenEnabled returns false, the browser guarantees that a requestFullScreen made at that moment will be denied." So we just need to find the best name for it. The name should avoid suggesting requestFullScreen will definitely be granted. Several people thought "enabled" was the best term for that. If no-one can think of a better one, then I think we should go with the best we have.
We'd love to have this for Vimeo as well. I think that fullScreenEnabled makes sense. The sooner the better, as the experience sucks if our full screen button is there but doesn't work if the attribute isn't on the iframe.
*** This bug has been marked as a duplicate of bug 80660 ***