Summary: | [WK2] Enable fullscreen request from UIProcess (i.e. user command) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Bruno Abinader (history only) <bruno.abinader> | ||||||||
Component: | WebKit2 | Assignee: | Bruno Abinader (history only) <bruno.abinader> | ||||||||
Status: | RESOLVED INVALID | ||||||||||
Severity: | Normal | CC: | andersca, benjamin, cdumez, eric, jer.noble, laszlo.gombos, tmpsantos | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Bruno Abinader (history only)
2013-01-28 15:16:26 PST
Created attachment 185083 [details]
Patch
Proposed patch
Comment on attachment 185083 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=185083&action=review Overall, the addition of requestEnterFullScreen() looks good, but I recommend a r- due to the change to requestExitFullScreen. > Source/WebKit2/WebProcess/FullScreen/WebFullScreenManager.cpp:147 > +void WebFullScreenManager::requestEnterFullScreen() > +{ > + // Default to document.documentElement(). > + enterFullScreenForElement(m_page->corePage()->mainFrame()->document()->documentElement()); > +} > + LGTM. In the future, clients may want some way to specify which element they'd like to be the full-screen one (instead of documentElement()), but this is good for now. > Source/WebKit2/WebProcess/FullScreen/WebFullScreenManager.cpp:151 > - m_element->document()->webkitCancelFullScreen(); > + exitFullScreenForElement(m_element.get()); By not calling webkitCancelFullScreen(), I believe the contents of m_fullScreenElement and m_fullScreenElementStack won't be modified, which is not desirable. If you're not getting an exitFullScreenForElement() in response, it's probably because the element wasn't in full screen to begin with, and you'll have to handle that case explicitly in the UIProcess. Created attachment 185097 [details]
Patch
Removed changes on requestExitFullScreen as reviewed by Jer Noble.
(In reply to comment #3) > Created an attachment (id=185097) [details] > Patch > > Removed changes on requestExitFullScreen as reviewed by Jer Noble. Unofficial r+. I'm not a webkit2 owner, you'll have to deal with them. Comment on attachment 185097 [details]
Patch
-Not really an explanation for why that is needed.
-The fullscreen element is always the documentElement, that is not what the Fullscreen API is for.
-No test.
(In reply to comment #0) > While implementing fullscreen/window toggle (F11) in EFL's MiniBrowser, I've noticed there is no way other than using JS to request full screen view. This bug intends to implement a method to allow UIProcess (i.e. a user command flag or keyboard key associated to fullscreen toggle) to request full screen view to WebProcess, which handles the necessary user authorization request (accept/deny). The workflow works like this: It looks like you are mixing two concepts. The fullscreen API and the browser ability to run fullscreen. You do not need the Web Fullscreen API to show your browser fullscreen. You can just use your native functions to take the View and put it fullscreen. By abusing the Web Fullscreen API, you are altering the page state (the fullscreen extensions to the Document element) and you give a way for a page to get out of fullscreen. (In reply to comment #7) > (In reply to comment #0) > > While implementing fullscreen/window toggle (F11) in EFL's MiniBrowser, I've noticed there is no way other than using JS to request full screen view. This bug intends to implement a method to allow UIProcess (i.e. a user command flag or keyboard key associated to fullscreen toggle) to request full screen view to WebProcess, which handles the necessary user authorization request (accept/deny). The workflow works like this: > > It looks like you are mixing two concepts. The fullscreen API and the browser ability to run fullscreen. > > You do not need the Web Fullscreen API to show your browser fullscreen. You can just use your native functions to take the View and put it fullscreen. I understand one can simply call the platform's native API to enter fullscreen mode, however, as Jer mentioned, the CSS ComputedStyles does not get updated when this occurs. Indeed the current implementation is buggy in a sense that the Document fullscreen elements stack is not updated, this is what I'm planning to fix on the following patch. > > By abusing the Web Fullscreen API, you are altering the page state (the fullscreen extensions to the Document element) and you give a way for a page to get out of fullscreen. Isn't the page state supposed to be changed after we toggle fullscreen mode (i.e. activate CSS :fullscreen pseudo-class)? Created attachment 185135 [details]
Patch
Now using Document::requestFullScreenForElement for proper fullscreen element stack treatment.
Comment on attachment 185135 [details]
Patch
Not addressed my concerns.
No tests.
(In reply to comment #10) > (From update of attachment 185135 [details]) > Not addressed my concerns. > No tests. OK, let me try to clarify: Currently on Google Chrome, for instance, if you press the F11 key to go fullscreen mode, the document element is not notified, thus document.webkitIsFullScreen returns 'false' (you can verify this by going fullscreen on this example page - http://johndyer.name/lab/fullscreenapi/ ). My idea is to take advantage of the FullScreen API internals to provide proper style updates. By using only native API to provide fullscreen mode, I've noticed that at least for EFL platform, the app gets unexpected behavior when switching back to window mode. As you mentioned, yes, the document element is always the fullscreen element, this is why Document::requestEnterFullScreenForElement() sets documentElement() if 'element' parameter is invalid. I'm working on providing tests for this addition, but most important now is to have your opinion on the idea, or even suggest another approach other than using only native API. If this is still not desired, we can of course abort this patch submission. (In reply to comment #11) > (In reply to comment #10) > > (From update of attachment 185135 [details] [details]) > > Not addressed my concerns. > > No tests. > > OK, let me try to clarify: > > Currently on Google Chrome, for instance, if you press the F11 key to go fullscreen mode, the document element is not notified, thus document.webkitIsFullScreen returns 'false' (you can verify this by going fullscreen on this example page - http://johndyer.name/lab/fullscreenapi/ ). My idea is to take advantage of the FullScreen API internals to provide proper style updates. By using only native API to provide fullscreen mode, I've noticed that at least for EFL platform, the app gets unexpected behavior when switching back to window mode. > > As you mentioned, yes, the document element is always the fullscreen element, this is why Document::requestEnterFullScreenForElement() sets documentElement() if 'element' parameter is invalid. > > I'm working on providing tests for this addition, but most important now is to have your opinion on the idea, or even suggest another approach other than using only native API. If this is still not desired, we can of course abort this patch submission. Let's think about this from a WebApp standpoint: the WebApp won't go to fullscreen unless it wants to go fullscreen. Going further and comparing this use case with a native app, there is no way of the window manager forcing your, let's say, IRC client, to go fullscreen. If think the current behavior is correct: if the browser goes fullscreen, it is a resize from the WebApp perspective. Think your browser as a window manager: the WebApp might ask it to go fullscreen, but not the other way around. To complement: I'm myself a user of Chromium fullscreen sometimes (specially on netbooks). I would find it very very weird if I start to see websites changing their appearance because of that. (In reply to comment #12) > Let's think about this from a WebApp standpoint: the WebApp won't go to fullscreen unless it wants to go fullscreen. Going further and comparing this use case with a native app, there is no way of the window manager forcing your, let's say, IRC client, to go fullscreen. > > If think the current behavior is correct: if the browser goes fullscreen, it is a resize from the WebApp perspective. Think your browser as a window manager: the WebApp might ask it to go fullscreen, but not the other way around. Fair enough, as we discussed on IRC it is not up to the browser to decide for the WebApp to apply its fullscreen styles or not. However, from the debugging point of view, would it still have a chance as a debugging setting one can set up to force fullscreen style to be shown? Otherwise I agree we can skip this change. > Fair enough, as we discussed on IRC it is not up to the browser to decide for the WebApp to apply its fullscreen styles or not. Like Thiago, I think this particular approach is not going to fly. Web Fullscreen API is a weird little spec with special use cases and I would be cautious abusing it. BUT, I think you have an interesting idea that a webpage may be interested in knowing if it is going fullscreen. If you have solid use cases, that is worth raising the issue to the W3C. > However, from the debugging point of view, would it still have a chance as a debugging setting one can set up to force fullscreen style to be shown? Otherwise I agree we can skip this change. Any code has a cost. I don't think is worth is. It is already easy to debug fullscreen APIs. (In reply to comment #15) > > However, from the debugging point of view, would it still have a chance as a debugging setting one can set up to force fullscreen style to be shown? Otherwise I agree we can skip this change. > > Any code has a cost. I don't think is worth is. It is already easy to debug fullscreen APIs. Indeed, a couple JS calls can do the job. Thanks for the insightful discussion! |