Last Comment Bug 545812 - API for controlling fullscreen from content
: API for controlling fullscreen from content
Status: RESOLVED FIXED
[evang-wanted][secr:curtisk]
: dev-doc-complete
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 8 votes (vote)
: mozilla9
Assigned To: Chris Pearce (:cpearce)
:
:
Mentors:
https://wiki.mozilla.org/Platform/Fea...
: 527471 581214 585165 636411 652446 (view as bug list)
Depends on: 698340 698977 699354 699722 701258 702000 703367 705234 714809 718107 721026 725466 731029 746437 760422 517870 578265 678173 684618 684620 684625 684627 684628 685069 685402 685779 687687 688082 688648 689058 690989 691583 691947 692593 694204 694690 695158 695935 696918 697636 699885 700151 700764 701251 701260 701442 701640 701992 702146 702295 703079 704039 704709 706555 706672 708174 708553 712181 714675 716107 720278 721711 725311 726474 CVE-2012-0460 729872 730583 738275 738764 743198 744860 745067 748198 779286 779324 801891 805301 867967 947854 968526 1053783 1111099
Blocks: webapi 693369 gecko-games 470628 631042 702159 703881 1055977
  Show dependency treegraph
 
Reported: 2010-02-11 20:34 PST by Paul Rouget [:paul]
Modified: 2016-02-02 15:17 PST (History)
68 users (show)
dveditz: sec‑review+
cpearce: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Part 1: Window state goop, content events, styling. (19.29 KB, patch)
2010-12-06 16:20 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 3: Key disabling. (3.91 KB, patch)
2010-12-06 16:44 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 4: Extend nsGlobalWindow API with key disabling. (2.97 KB, patch)
2010-12-06 16:44 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 4 (30.98 KB, patch)
2010-12-06 16:44 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 5: Frontend prototype. (1.18 KB, patch)
2010-12-06 16:45 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 1: Window state goop, content events, styling. (19.30 KB, patch)
2010-12-06 17:46 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 2: Chrome events, request API. (31.00 KB, patch)
2010-12-06 17:47 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 1: Window state goop, content events, styling. (19.30 KB, patch)
2010-12-06 19:24 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Part 2: Chrome events, request API. (32.48 KB, patch)
2010-12-06 19:24 PST, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Patch 1 v1: dom/content changes for full-screen api (25.31 KB, patch)
2011-08-04 15:16 PDT, Chris Pearce (:cpearce)
no flags Details | Diff | Splinter Review
Patch 2 v1: -moz-full-screen CSS pseudo class (6.24 KB, patch)
2011-08-04 15:18 PDT, Chris Pearce (:cpearce)
bzbarsky: review-
Details | Diff | Splinter Review
Patch 3 v1: dom fullscreenchange event (11.58 KB, patch)
2011-08-04 15:21 PDT, Chris Pearce (:cpearce)
bugs: review+
Details | Diff | Splinter Review
Patch 4 v1: iframe.mozallowfullscreen (4.85 KB, patch)
2011-08-04 15:22 PDT, Chris Pearce (:cpearce)
jst: review+
Details | Diff | Splinter Review
Patch 6 v1: Don't animate toolbar hide on dom full-screen (4.22 KB, patch)
2011-08-04 15:33 PDT, Chris Pearce (:cpearce)
dao+bmo: review-
Details | Diff | Splinter Review
Patch 7 v1: mochitests (8.10 KB, patch)
2011-08-04 15:38 PDT, Chris Pearce (:cpearce)
no flags Details | Diff | Splinter Review
Patch 1 v2: dom/content changes for full-screen api (24.78 KB, patch)
2011-08-10 20:24 PDT, Chris Pearce (:cpearce)
jst: review-
Details | Diff | Splinter Review
Patch 2 v2: -moz-full-screen CSS pseudo class (8.17 KB, patch)
2011-08-10 20:27 PDT, Chris Pearce (:cpearce)
bzbarsky: review+
Details | Diff | Splinter Review
Patch 3 v1: dom mozfullscreenchange event (7.93 KB, patch)
2011-08-10 20:30 PDT, Chris Pearce (:cpearce)
cpearce: review+
Details | Diff | Splinter Review
Patch 5 v1: -moz-full-screen media query (5.43 KB, patch)
2011-08-10 20:37 PDT, Chris Pearce (:cpearce)
no flags Details | Diff | Splinter Review
Patch 7 v2: mochitests (8.05 KB, patch)
2011-08-10 20:40 PDT, Chris Pearce (:cpearce)
jst: review+
Details | Diff | Splinter Review
Patch 8 v1: Only grant full-screen requests in trusted contexts (12.53 KB, patch)
2011-08-10 20:44 PDT, Chris Pearce (:cpearce)
bugs: review+
Details | Diff | Splinter Review
Patch 8 v2: Only grant full-screen requests in trusted contexts (12.35 KB, patch)
2011-08-14 16:01 PDT, Chris Pearce (:cpearce)
cpearce: review+
Details | Diff | Splinter Review
Patch 9 v1: Restrict key input while in full-screen mode (7.13 KB, patch)
2011-08-18 21:28 PDT, Chris Pearce (:cpearce)
bugs: review-
Details | Diff | Splinter Review
Patch 10 v1: Exit full-screen mode on escape press (4.71 KB, patch)
2011-08-18 21:35 PDT, Chris Pearce (:cpearce)
bugs: review-
Details | Diff | Splinter Review
Patch 11 v1: Test full-screen key event restriction and escape-key-exit (10.09 KB, patch)
2011-08-18 21:37 PDT, Chris Pearce (:cpearce)
bugs: review-
Details | Diff | Splinter Review
Patch 9: Break out of full-screen mode upon non-alphanumeric key input (24.89 KB, patch)
2011-08-22 16:06 PDT, Chris Pearce (:cpearce)
bugs: review+
Details | Diff | Splinter Review
Patch 4 v1: iframe.mozallowfullscreen (4.90 KB, patch)
2011-08-22 17:35 PDT, Chris Pearce (:cpearce)
cpearce: review+
Details | Diff | Splinter Review
Patch 1 v3: dom/content changes for full-screen api (23.54 KB, patch)
2011-08-23 21:39 PDT, Chris Pearce (:cpearce)
no flags Details | Diff | Splinter Review
Patch 1 v4 dom/content changes for full-screen api (23.62 KB, patch)
2011-08-24 16:27 PDT, Chris Pearce (:cpearce)
jst: review+
Details | Diff | Splinter Review
WIP Patch: e10s support (12.66 KB, patch)
2011-08-31 21:40 PDT, Chris Pearce (:cpearce)
no flags Details | Diff | Splinter Review

Description Paul Rouget [:paul] 2010-02-11 20:34:52 PST
Webkit does it.
Do we want to provide the same feature?

Feature requested by:
http://blog.jilion.com/2010/02/11/sublimevideo-supports-firefox
Comment 1 Matthew Gregan [:kinetik] 2010-02-11 20:46:28 PST
It's not really alt-click to fullscreen, they're using some WebKit specific methods to support fullscreen from script (http://trac.webkit.org/changeset/50893).

There's a discussion on the WhatWG mailing list about what the API should look like.  The thread starts here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024860.html
Comment 2 Zeno Crivelli 2010-02-12 02:37:29 PST
Yes, an API to make the <video> go fullscreen would be really appreciated.

Robert O'Callahan wrote a proposal here:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg19915.html

He propose "enterFullscreen()".
"enterFullScreen()" [uppercase S] might be even better to be in harmony with the existing WebKit API, but anyway...

Regarding the "security" issues, the WebKit team is preventing programmatic call to that function and the API can be only triggered via a user click.

At this point the transition effect to go fullscreen is secondary IMHO, one should focus on simply getting the API to execute the same action that is called when the user chooses "Full Screen" from the contextual menu (or when clicking the fullscreen button in the built-in controls).

—Zeno
Jilion.com
Comment 3 Miles Lane 2010-04-25 17:49:05 PDT
I am currently deciding whether to attempt to implement a slideshow application in Flash or HTML5/CSS3/Javascript.  I am not a proficient programmer, so I am unsure I want to tackle drawing everything on the HTML5 canvas with Javascript.  I am interested in being able to create the slideshow and enable the user to switch to true fullscreen display.  I haven't decided yet whether to implement two layouts (4:3 and 16:9) and then allow those to be scaled up or down.  So, will the work you are discussing simply scale whatever is on the canvas?  Also, would be displaying UI controls and text boxes on top of the scaled graphical background.  Would all that work?  Will this be hard for a mediocre programmer to tackle (my background is software testing).
Comment 4 Pierre Rudloff 2010-06-02 13:45:18 PDT
W3C does not recommend that:
"User agents should not provide a public API to cause videos to be shown full-screen. A script, combined with a carefully crafted video file, could trick the user into thinking a system-modal dialog had been shown, and prompt the user for a password. There is also the danger of "mere" annoyance, with pages launching full-screen videos when links are clicked or pages navigated. Instead, user-agent-specific interface features may be provided to easily allow the user to obtain a full-screen playback mode."
(http://www.w3.org/TR/html5/video.html)
Comment 5 Zeno Crivelli 2010-06-02 15:02:41 PDT
Pierre, don't worry, the Mozilla folks are very aware of this...
I was also mentioning it in my previous comment ("security issues"), and there're trivial solutions to this...

—Zeno
Comment 6 Biju 2010-06-20 16:45:38 PDT
(In reply to comment #2)
> Yes, an API to make the <video> go fullscreen would be really appreciated.

Zeno, can u try following at Jilion.com
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026803.html
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-07-23 13:40:43 PDT
I thought about this a fair bit a few weeks ago, and wrote some detailed notes on how I think this should work that expand on my WHATWG proposal.
https://wiki.mozilla.org/Gecko:FullScreenAPI
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-08-03 17:06:45 PDT
*** Bug 581214 has been marked as a duplicate of this bug. ***
Comment 9 Dão Gottwald [:dao] 2010-08-07 01:24:06 PDT
*** Bug 585165 has been marked as a duplicate of this bug. ***
Comment 10 Dão Gottwald [:dao] 2010-08-07 01:27:26 PDT
(In reply to comment #3)
> I am currently deciding whether to attempt to implement a slideshow application
> in Flash or HTML5/CSS3/Javascript.  I am not a proficient programmer, so I am
> unsure I want to tackle drawing everything on the HTML5 canvas with Javascript.
>  I am interested in being able to create the slideshow and enable the user to
> switch to true fullscreen display.  I haven't decided yet whether to implement
> two layouts (4:3 and 16:9) and then allow those to be scaled up or down.  So,
> will the work you are discussing simply scale whatever is on the canvas?  Also,
> would be displaying UI controls and text boxes on top of the scaled graphical
> background.  Would all that work?  Will this be hard for a mediocre programmer
> to tackle (my background is software testing).

You want window.fullScreen = true
Comment 11 Dão Gottwald [:dao] 2010-08-07 01:35:06 PDT
(In reply to comment #10)
> You want window.fullScreen = true

Oops, sorry, apparently this is read-only without chrome privileges.
Comment 12 Josh Matthews [:jdm] 2010-12-06 16:20:48 PST
Created attachment 495682 [details] [diff] [review]
Part 1: Window state goop, content events, styling.
Comment 13 Josh Matthews [:jdm] 2010-12-06 16:23:28 PST
I'm going to be dumping my rebased WIP patches from September in this bug mainly for safekeeping.  They're not really worth looking at yet unless you're keenly interested in watching me fumble my way along.
Comment 14 Josh Matthews [:jdm] 2010-12-06 16:44:10 PST
Created attachment 495689 [details] [diff] [review]
Part 3: Key disabling.
Comment 15 Josh Matthews [:jdm] 2010-12-06 16:44:28 PST
Created attachment 495690 [details] [diff] [review]
Part 4: Extend nsGlobalWindow API with key disabling.
Comment 16 Josh Matthews [:jdm] 2010-12-06 16:44:42 PST
Created attachment 495691 [details] [diff] [review]
Part 4
Comment 17 Josh Matthews [:jdm] 2010-12-06 16:45:48 PST
Created attachment 495692 [details] [diff] [review]
Part 5: Frontend prototype.
Comment 18 Josh Matthews [:jdm] 2010-12-06 17:46:26 PST
Created attachment 495721 [details] [diff] [review]
Part 1: Window state goop, content events, styling.
Comment 19 Josh Matthews [:jdm] 2010-12-06 17:47:34 PST
Created attachment 495722 [details] [diff] [review]
Part 2: Chrome events, request API.
Comment 20 Josh Matthews [:jdm] 2010-12-06 19:24:33 PST
Created attachment 495744 [details] [diff] [review]
Part 1: Window state goop, content events, styling.
Comment 21 Josh Matthews [:jdm] 2010-12-06 19:24:47 PST
Created attachment 495745 [details] [diff] [review]
Part 2: Chrome events, request API.
Comment 22 Mike Beltzner [:beltzner, not reading bugmail] 2011-02-24 09:06:56 PST
*** Bug 636411 has been marked as a duplicate of this bug. ***
Comment 23 Josh Matthews [:jdm] 2011-04-01 21:00:18 PDT
I'm not working on this at the moment, no matter how much I wish I were.
Comment 24 Jo Hermans 2011-04-24 14:04:58 PDT
*** Bug 652446 has been marked as a duplicate of this bug. ***
Comment 25 Matthew Gregan [:kinetik] 2011-04-25 18:07:14 PDT
*** Bug 652446 has been marked as a duplicate of this bug. ***
Comment 26 Jake 2011-05-07 11:08:36 PDT
(In reply to comment #4)
> W3C does not recommend that:
> "User agents should not provide a public API to cause videos to be shown
> full-screen. A script, combined with a carefully crafted video file, could
> trick the user into thinking a system-modal dialog had been shown, and
> prompt the user for a password. There is also the danger of "mere"
> annoyance, with pages launching full-screen videos when links are clicked or
> pages navigated. Instead, user-agent-specific interface features may be
> provided to easily allow the user to obtain a full-screen playback mode."
> (http://www.w3.org/TR/html5/video.html)
You know why each time you go full screen on flash there is a banner in the middle telling you "press esc to quit"? I think they have the same concern. Actually I find it annoying, Fx should come up with a better idea, e.g. popping up a warning when user go screen the first time on a site and user can check "never warn me again on this site", this way it only annoy you once.
Comment 27 Chris Pearce (:cpearce) 2011-06-30 16:24:56 PDT
I'll see if I can make some progress on this.
Comment 28 Jared Wein [:jaws] (please needinfo? me) 2011-07-22 14:53:36 PDT
Has there been any progress made on this bug?

I'd like to take bug 470628 (which depends on this bug), but am curious as to how far out a patch for this bug may land.
Comment 29 Chris Pearce (:cpearce) 2011-07-22 17:43:56 PDT
Yes. I have patches that work which are based on trunk which implements all the new methods and attributes in the spec, but I don't have any tests or UI. I also haven't addressed the finer points of the security considerations listed on the spec page, so I may require some more refactoring. Hopefully I'll have something up for review next week.
Comment 30 Justin Dolske [:Dolske] 2011-07-25 18:11:44 PDT
Couple of random thoughts (which probably end up being followups, but might as well ask now).

1) We've talked a bit about full-tab perhaps being desirable in addition to full-screen. Will this same API/implementation be adaptable to support full-tab as well? I'm not sure if we need to expose the distinction to content, it could just be a UA option.

2) Will this implementation be flexible enough to allow smooth transitions between fullscreen (or fulltab) and normal mode? For example, see what Safari does... Instead of blinking between the two modes, the video zooms in/out while the rest of the screen fades in/out. It's not just a cool effect, but makes it very clear what's happening.
Comment 31 Anthony Ricaud (:rik) 2011-07-26 00:12:32 PDT
Just FYI, Safari does not have a smooth transition with this API. Only with the fullscreen video.
Comment 32 Zeno Crivelli 2011-07-26 00:52:04 PDT
Right: if the element is not a video you won't get the zoom (growing/shrinking) transition, but you'll still get the fade-in/out transition on the whole screen.
Comment 33 Dão Gottwald [:dao] 2011-07-26 03:04:14 PDT
(In reply to comment #30)
> 1) We've talked a bit about full-tab perhaps being desirable in addition to
> full-screen. Will this same API/implementation be adaptable to support
> full-tab as well? I'm not sure if we need to expose the distinction to
> content, it could just be a UA option.

Exposing it to content seems slightly strange, since it can already do full-tab. E.g. youtube's poor man's fullscreen mode for html5 video.
Comment 34 Jake 2011-07-26 06:12:17 PDT
(In reply to comment #32)
> Right: if the element is not a video you won't get the zoom
> (growing/shrinking) transition, but you'll still get the fade-in/out
> transition on the whole screen.

Hopefully all the growing/shrinking fade-in/out can be turned off, it only makes the transition sluggish.
Comment 35 AndreiD[QA] 2011-07-29 01:52:26 PDT
Is it ok if we add to the "URL" field of this bug the feature's wiki page? Just for better tracking purposes. Thanks.
https://wiki.mozilla.org/Platform/Features/Full_Screen_APIs
Comment 36 Chris Pearce (:cpearce) 2011-08-04 15:16:30 PDT
Created attachment 550849 [details] [diff] [review]
Patch 1 v1: dom/content changes for full-screen api

Implement the base changes to document and element, except the "withkeys" functions, and no security constraints. The API is only enabled when the full-screen-api.enabled pref is set to true. 

See the spec at https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI

Special thanks to Josh Matthews whose patches formed the base of my work, and made getting started a lot easier.

Question: would the reference to the full-screen element be better off as a weak reference?
Comment 37 Chris Pearce (:cpearce) 2011-08-04 15:18:58 PDT
Created attachment 550852 [details] [diff] [review]
Patch 2 v1: -moz-full-screen CSS pseudo class

Style sheet changes required to make the current full-screen element have the -moz-full-screen pseudo class apply, and the stlye rules required to make the full-screen element encompass the whole screen.
Comment 38 Chris Pearce (:cpearce) 2011-08-04 15:21:20 PDT
Created attachment 550854 [details] [diff] [review]
Patch 3 v1: dom fullscreenchange event

Dispatch a fullscreenchange event when we go into, or leave, DOM full-screen mode.

Question: This is a mozilla-specific API at this stage, should this event be called mozfullscreenchange instead?
Comment 39 Chris Pearce (:cpearce) 2011-08-04 15:22:29 PDT
Created attachment 550855 [details] [diff] [review]
Patch 4 v1: iframe.mozallowfullscreen

Restrict HTMLElement.mozRequestFullScreen so that it's only granted if all ancestor iframes have the mozallowfullscreen attribute set.
Comment 40 Chris Pearce (:cpearce) 2011-08-04 15:33:16 PDT
Created attachment 550861 [details] [diff] [review]
Patch 6 v1: Don't animate toolbar hide on dom full-screen

Don't animate the toolbar hide when we enter DOM full-screen mode, and exit DOM full-screen on escape key press. I think we should run with this until we implement a "you've entered full-screen mode, press ESC to exit" drop down, or something equivalent.

I also want this so that when I get reftests (or reftest-like mochitests which compare screenshots) I won't need to worry about a half hidden toolbar causing screengrab comparisons in reftests to fail.
Comment 41 Chris Pearce (:cpearce) 2011-08-04 15:38:43 PDT
Created attachment 550863 [details] [diff] [review]
Patch 7 v1: mochitests

Mochitests for the content changes. I was trying to use WindowSnapshot.js to compare full-screen screenshots to verify that full-screen was working, but that was failing randomly I think due to timing issues, so I've removed those tests and will add them in again later when I figure out how to do them reliably.
Comment 42 Chris Pearce (:cpearce) 2011-08-04 16:42:43 PDT
Roc and I discussed this, and we decided we'd start out by following the Flash model of just displaying a warning when you enter full-screen mode. This way it's not so critical to implement the "withKeys" API variants, since the user should always know when they've entered full-screen.

Other remaining ToDo items are roughly:
* Must decide what to do when user exits browser while in dom full-screen mode. Currently the full-screened-ness is restored on restart, but the dom full-screen mode isn't. Something needs to change here.
* Change-tab (including open new tab in foreground) should break out of full-screen mode.
* Disable plugins in full-screen mode documents (do we still need to do this if we don't implement the "withKeys" api variants?).
* Implement the "you're in full-screen mode. ok/exit" UI/popdown.
Comment 43 Chris Pearce (:cpearce) 2011-08-04 17:19:19 PDT
Another ToDo:
* We should only allow mozRequestFullScreen() to go full-screen mode when running in a trusted event context (like a user mouse click event).
Comment 44 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-04 17:53:24 PDT
(In reply to comment #42)
> * Must decide what to do when user exits browser while in dom full-screen
> mode. Currently the full-screened-ness is restored on restart, but the dom
> full-screen mode isn't. Something needs to change here.

I'm not sure, but I think restoring user-initiated fullscreen but not DOM-initiated fullscreen would be the best.

> * Disable plugins in full-screen mode documents (do we still need to do this
> if we don't implement the "withKeys" api variants?).

Probably not. I think for now we just shouldn't implement a withKeys method at all. Later if we implement it, we would ensure plugins are disabled when it is used.

One other item is to do a smooth zoom-out transition from the fullscreen element, but that can be another bug.
Comment 45 Chris Pearce (:cpearce) 2011-08-04 21:14:51 PDT
Also, try builds with the above patches applied are available here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/cpearce@mozilla.com-938cd232dd3f/
Comment 46 Jake 2011-08-04 21:55:30 PDT
(In reply to comment #42)
> Roc and I discussed this, and we decided we'd start out by following the
> Flash model of just displaying a warning when you enter full-screen mode.
> This way it's not so critical to implement the "withKeys" API variants,
> since the user should always know when they've entered full-screen.

Is there a pref like "pref("full-screen.warning.enabled", false);" for experienced user to turn it off ? or allow user to set warning time?
Comment 47 Bogdan Bivolaru 2011-08-04 23:14:29 PDT
Is it possible to specify site-specific preferences about this feature?
Such as allow this site to store cookies, run Javascript, open pop-ups,...

There are other features that might need website specific permissions (access to hardware such as microphone, camera). Could you integrate this in a larger permission related module, maybe in a future version?
Comment 48 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2011-08-05 00:56:33 PDT
(In reply to Chris Pearce [:cpearce] from comment #42)
> Roc and I discussed this, and we decided we'd start out by following the
> Flash model of just displaying a warning when you enter full-screen mode.
> This way it's not so critical to implement the "withKeys" API variants,
> since the user should always know when they've entered full-screen.

Will the non-withKeys version still ban keys from day 1? (I scanned thought the patches and didn't notice key filtering code. It would be bad if the first release allowed keys in the non-withKeys variant preventing taking the keys away from sites later.)
Comment 49 Dão Gottwald [:dao] 2011-08-05 01:29:15 PDT
Comment on attachment 550861 [details] [diff] [review]
Patch 6 v1: Don't animate toolbar hide on dom full-screen

>Bug 545812 - Don't animate the toolbar hide when switching to DOM API full-screen mode. r=?

>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js

>     if (enterFS) {
>-      // Add a tiny toolbar to receive mouseover and dragenter events, and provide affordance.
>-      // This will help simulate the "collapse" metaphor while also requiring less code and
>-      // events than raw listening of mouse coords.
>-      let fullScrToggler = document.getElementById("fullscr-toggler");
>-      if (!fullScrToggler) {
>-        fullScrToggler = document.createElement("hbox");
>-        fullScrToggler.id = "fullscr-toggler";
>-        fullScrToggler.collapsed = true;
>-        gNavToolbox.parentNode.insertBefore(fullScrToggler, gNavToolbox.nextSibling);
>+      if (document.mozFullScreen) {
>+        this._shouldAnimate = false;

What exactly is document.mozFullScreen?
Comment 50 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-05 01:44:44 PDT
(In reply to Bogdan Bivolaru from comment #47)
> There are other features that might need website specific permissions
> (access to hardware such as microphone, camera). Could you integrate this in
> a larger permission related module, maybe in a future version?

I don't think that's a good idea:
http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html
But we should discuss that somewhere else.

(In reply to Henri Sivonen (:hsivonen) from comment #48)
> (In reply to Chris Pearce [:cpearce] from comment #42)
> > Roc and I discussed this, and we decided we'd start out by following the
> > Flash model of just displaying a warning when you enter full-screen mode.
> > This way it's not so critical to implement the "withKeys" API variants,
> > since the user should always know when they've entered full-screen.
> 
> Will the non-withKeys version still ban keys from day 1? (I scanned thought
> the patches and didn't notice key filtering code. It would be bad if the
> first release allowed keys in the non-withKeys variant preventing taking the
> keys away from sites later.)

Actually I got this wrong. what we should do is implement withKeys *only* at first. It's the non-withKeys version that we should not implement until we actually implement the key-disabling code.
Comment 51 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-05 02:17:46 PDT
Comment on attachment 550854 [details] [diff] [review]
Patch 3 v1: dom fullscreenchange event

># HG changeset patch
># Parent 2b611319841e4195413aaa885a5c36718c79d60d
>Bug 545812 - Dispatch fullscreenchange event when we change full-screen mode. r=?
>
>diff --git a/content/base/src/nsContentUtils.cpp b/content/base/src/nsContentUtils.cpp
>--- a/content/base/src/nsContentUtils.cpp
>+++ b/content/base/src/nsContentUtils.cpp
>@@ -653,17 +653,18 @@ nsContentUtils::InitializeEventTable() {
>     { nsGkAtoms::ondevicemotion,                NS_DEVICE_MOTION, EventNameType_None, NS_EVENT },
>     { nsGkAtoms::ondeviceorientation,           NS_DEVICE_ORIENTATION, EventNameType_None, NS_EVENT },
> 
>     { nsGkAtoms::ontransitionend,               NS_TRANSITION_END, EventNameType_None, NS_TRANSITION_EVENT },
>     { nsGkAtoms::onanimationstart,              NS_ANIMATION_START, EventNameType_None, NS_ANIMATION_EVENT },
>     { nsGkAtoms::onanimationend,                NS_ANIMATION_END, EventNameType_None, NS_ANIMATION_EVENT },
>     { nsGkAtoms::onanimationiteration,          NS_ANIMATION_ITERATION, EventNameType_None, NS_ANIMATION_EVENT },
>     { nsGkAtoms::onbeforeprint,                 NS_BEFOREPRINT, EventNameType_HTMLXUL, NS_EVENT },
>-    { nsGkAtoms::onafterprint,                  NS_AFTERPRINT, EventNameType_HTMLXUL, NS_EVENT }
>+    { nsGkAtoms::onafterprint,                  NS_AFTERPRINT, EventNameType_HTMLXUL, NS_EVENT },
>+    { nsGkAtoms::onfullscreenchange,            NS_FULLSCREENCHANGE, EventNameType_HTML, NS_EVENT_NULL }
Yes, I think the event should have moz prefix if we don't have a spec for this.
FYI, bz is changing InitializeEventTable, Bug 675405, so one of you will need to update the patch a bit.


>+class nsDispatchFullScreenChange : public nsRunnable {
{ should be in the next line


>+public:
>+  nsDispatchFullScreenChange(nsIDocument *aDoc,
>+                             nsIDOMDocument *aDomDoc)
>+    : mDoc(aDoc)
>+  {
>+    mTarget = aDoc->GetFullScreenElement();
>+    if (!mTarget) {
>+      mTarget = aDomDoc;
>+    }
>+  }
There shouldn't be need for aDomDoc. Just set mTarget to point aDoc.


> void nsDocument::UpdateFullScreenStatus(PRBool aIsFullScreen) {
>+  // Only maintain full-screen state on DOM documents.
>+  nsCOMPtr<nsIDOMDocument> domDoc = do_QueryInterface(static_cast<nsIDocument*>(this));
>+  if (!domDoc)
>+    return;
So, there shouldn't be need for domDoc variable.
Comment 52 Boris Zbarsky [:bz] (still a bit busy) 2011-08-05 07:45:09 PDT
Comment on attachment 550852 [details] [diff] [review]
Patch 2 v1: -moz-full-screen CSS pseudo class

So this is wrong on its face (why is it adding an unused NS_EVENT_STATE_FULL_SCREEN, adding two different atoms for the :-moz-full-screen pseudoclass, etc), and I'm not sure whether it even gives correct behavior....

Specific questions:

1)  can the full-screen element of a document change without the full-screen
    document state changing?
2)  Why do we really need the full-screen document state (changes to which force
    a complete restyle on everything in the document)?
3)  If an element is full-screen, are all its containing frames expected to
    match -moz-full-screen?
4)  Is there a reason that we set up the bool pref var cache for
    IsFullScreenApiEnabled lazily?  Doing that violates the constraint we're
    trying to enforce where selector matching doesn't mutate any state....
Comment 53 Chris Pearce (:cpearce) 2011-08-07 15:43:03 PDT
(In reply to Dão Gottwald [:dao] from comment #49)
> What exactly is document.mozFullScreen?

Dão: It means that an element owned by the document has requested that the document go into full-screen mode, and if the element is in the document, the element will be expanded to encompass the entire screen.

This enables us to distinguish between the user pressing F11 to put the window into full-screen mode from an element in the document requesting full-screen mode, so that UI can behave accordingly.
Comment 54 Chris Pearce (:cpearce) 2011-08-07 19:19:22 PDT
(In reply to Boris Zbarsky (:bz) from comment #52)
> Comment on attachment 550852 [details] [diff] [review] [diff] [details] [review]
> Patch 2 v1: -moz-full-screen CSS pseudo class

Thanks for reviewing this.

> So this is wrong on its face (why is it adding an unused
> NS_EVENT_STATE_FULL_SCREEN, adding two different atoms for the
> :-moz-full-screen pseudoclass, etc),

Ah oops, detritus from a previous version.

> and I'm not sure whether it even gives
> correct behavior....

Behaviour appears correct based on my testing. ;) I linked to a try build in comment 45 if you or anyone wants to test themselves. Test page at: http://pearce.org.nz/full-screen/
 
> Specific questions:
> 
> 1)  can the full-screen element of a document change without the full-screen
>     document state changing?

Yes. If a document is in full-screen mode, and another element requests full-screen, the other element will become the full-screen element, and have the css-pseudo class change to apply to it and not the original full-screen element.

> 2)  Why do we really need the full-screen document state (changes to which
> force
>     a complete restyle on everything in the document)?

I tried removing the document state, but when I do that, if an element requests full-screen while another element is already the full-screen element, the pseudo-class doesn't switch apply to the new full-screen element. Is there a way to force the pseudo-class to be re-evaluated only on the affected elements? Perhaps this is what you're getting at in question 1?

> 3)  If an element is full-screen, are all its containing frames expected to
>     match -moz-full-screen?

Yes, iframes which contain the full-screen element will match. Note that nsIDocument::GetFullScreenElement() returns the full-screen element when the full-screen element is in the current document, or the element which contains the full-screen element if the full-screen element is in a child document. So the ePseudoClass_mozFullScreenElement case in SelectorMatches() will Just Work and apply the pseudo-class to containing documents as well.

> 4)  Is there a reason that we set up the bool pref var cache for
>     IsFullScreenApiEnabled lazily?  Doing that violates the constraint we're
>     trying to enforce where selector matching doesn't mutate any state....

How about I put the pref var cache in nsContentUtils::Init()?
Comment 55 Dão Gottwald [:dao] 2011-08-08 02:30:23 PDT
(In reply to Chris Pearce [:cpearce] from comment #53)
> (In reply to Dão Gottwald [:dao] from comment #49)
> > What exactly is document.mozFullScreen?
> 
> Dão: It means that an element owned by the document has requested that the
> document go into full-screen mode, and if the element is in the document,
> the element will be expanded to encompass the entire screen.

You're querying the chrome document here, though.
Comment 56 Chris Pearce (:cpearce) 2011-08-08 14:49:22 PDT
bz: see comment 54 for answers to your questions.
Comment 57 Boris Zbarsky [:bz] (still a bit busy) 2011-08-08 17:08:36 PDT
Sorry I wasn't cced...

> Perhaps this is what you're getting at in question 1?

Yes.   ;)  It sounds like the document state thing is just hiding the lack of dynamic change handling for the other bit by recomputing everything.

I think the right way to handle this is probably to just get rid of the document state altogether (unless you need it elsewhere for some reason) and certainly to not look at that document state from the style system.  Instead, just track the fullscreen state of elements.  In particular, see mozilla::dom::Element::AddStates/RemoveStates.  If you just add an event state bit for this (as you do), do the event state pseudoclass thing, and call AddStates/RemoveStates on elements that start/stop being a fullscreen element, the style system end should just work.  Furthermore, if it's an event state pseudoclass you won't even need to add any code to the rule processor.  AddStates/RemoveStates are private, so you may need to add a friend class unless one of the ESM, global window, or focus manager is doing the state-setting.  Or I guess we could just make them public...  I really wish C++ had a way to expose a particular method to particular classes.  :(

> How about I put the pref var cache in nsContentUtils::Init()?

Sounds great.
Comment 58 Chris Pearce (:cpearce) 2011-08-08 18:36:21 PDT
(In reply to Dão Gottwald [:dao] from comment #55)
> (In reply to Chris Pearce [:cpearce] from comment #53)
> > (In reply to Dão Gottwald [:dao] from comment #49)
> > > What exactly is document.mozFullScreen?
> > 
> > Dão: It means that an element owned by the document has requested that the
> > document go into full-screen mode, and if the element is in the document,
> > the element will be expanded to encompass the entire screen.
> 
> You're querying the chrome document here, though.

Dão: When a dom document is in full-screen state, all ancestor documents are in full-screen state as well, including the ancestor chrome document.

See the proposed specification at:
https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI
Comment 59 Jesse Ruderman 2011-08-08 22:09:48 PDT
I am opposed to this feature. I don't think a flashed warning is sufficient even for a non-keys version. See https://wiki.mozilla.org/Gecko:FullScreenAPI#Jesse.27s_concerns
Comment 60 Dão Gottwald [:dao] 2011-08-09 02:02:22 PDT
(In reply to Chris Pearce [:cpearce] from comment #58)
> (In reply to Dão Gottwald [:dao] from comment #55)
> > (In reply to Chris Pearce [:cpearce] from comment #53)
> > > (In reply to Dão Gottwald [:dao] from comment #49)
> > > > What exactly is document.mozFullScreen?
> > > 
> > > Dão: It means that an element owned by the document has requested that the
> > > document go into full-screen mode, and if the element is in the document,
> > > the element will be expanded to encompass the entire screen.
> > 
> > You're querying the chrome document here, though.
> 
> Dão: When a dom document is in full-screen state, all ancestor documents are
> in full-screen state as well, including the ancestor chrome document.

And this is going to work with separate chrome/content processes?
Comment 61 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-09 03:09:09 PDT
(In reply to Jesse Ruderman from comment #59)
> I am opposed to this feature. I don't think a flashed warning is sufficient
> even for a non-keys version. See
> https://wiki.mozilla.org/Gecko:FullScreenAPI#Jesse.27s_concerns

Have there been any attacks of that nature using Flash?

Can you elaborate on why a Flash-style warning fails to mitigate the spoofing risks you describe?

We should minimize the risk here, but this feature is needed.
Comment 62 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-09 03:24:30 PDT
> Can you elaborate on why a Flash-style warning fails to mitigate the spoofing
> risks you describe?

This is an honest question, not a parry. I want to understand this to get a better idea of what might address your concerns.
Comment 63 Chris Pearce (:cpearce) 2011-08-09 18:51:54 PDT
(In reply to Dão Gottwald [:dao] from comment #60)
> (In reply to Chris Pearce [:cpearce] from comment #58)
> > (In reply to Dão Gottwald [:dao] from comment #55)
> > > You're querying the chrome document here, though.
> > 
> > Dão: When a dom document is in full-screen state, all ancestor documents are
> > in full-screen state as well, including the ancestor chrome document.
> 
> And this is going to work with separate chrome/content processes?

Currently this won't work with separate chrome/content processes, but we'll make this work cross-process in a follow up bug.

AFAICT window.fullscreen doesn't work cross-process yet either.
Comment 64 Dão Gottwald [:dao] 2011-08-10 00:07:07 PDT
(In reply to Chris Pearce [:cpearce] from comment #63)
> > > > You're querying the chrome document here, though.
> > > 
> > > Dão: When a dom document is in full-screen state, all ancestor documents are
> > > in full-screen state as well, including the ancestor chrome document.
> > 
> > And this is going to work with separate chrome/content processes?
> 
> Currently this won't work with separate chrome/content processes, but we'll
> make this work cross-process in a follow up bug.

What exactly is that followup work going to involve? Do you have a concrete plan?

> AFAICT window.fullscreen doesn't work cross-process yet either.

Maybe, but window.fullScreen isn't new. We should try to make new features e10s-ready from the start and avoid adding more to the pile of things that need to be fixed.
Comment 65 Jesse Ruderman 2011-08-10 10:47:52 PDT
> Can you elaborate on why a Flash-style warning fails to mitigate the spoofing 
> risks you describe?

* User might not be looking at the screen.

* Site site might add visual distractions during the transition. I saw a demo where a bunch of similarly-styled messaged appeared at once; the chance of someone reading the one saying "Press Esc to exit full screen mode" seemed low.

* Site might make it seem as if the "Press Esc to exit full screen mode" is part of an image (e.g. a banner ad or instructional screenshot) rather than something the browser is saying right now.

* Site might fake the opposite transition, as if the video finished and exited full screen mode, leaving the user believing they are no longer in full screen mode.

* Even after seeing the "Press Esc to exit full screen mode" message, the illusion may be strong enough on its own to convince the user they are not in full screen mode.

Some of these concerns can be mitigated by positioning the warning to appear near the top of the screen, rather than in the middle, so it is forced to overlap with the fake toolbars.

Some of these concerns diminish once users are accustomed to watching full-screen videos, learning what the messages look like and getting used to pressing Esc after a video finishes.

FWIW, even Flash, which routinely chooses to subvert browser security in order to have "unique functionality", chose not to allow keyboard input in auto-full-screen mode.

> We should minimize the risk here, but this feature is needed.

I'm not convinced this feature is needed. A full-screen button in the titlebar would cover all the common cases (the page has only one video element; the page has several video elements but only one is playing). And we need that button on the titlebar anyway, at least on Lion.
Comment 66 Robert Accettura [:raccettura] 2011-08-10 11:06:59 PDT
1.  This sounds like the most invasive/annoying popup/popbehind ad ever.  Once the user interacts with the page somewhere it jumps at you.

2.  Jesse's points seem valid, in particular regarding esc spoofing.  It's now very possible to make a convincing duplicate of the Firefox UI (even without XUL), especially as it's reduced in scope.  It's even possible to detect OS and mimic that enough (really just a menubar of some sort).  That would make a very convincing decoy to many users.

You could likely mitigate some of that by leaving a small semi-transparent bug in the top right corner (personal pref on location) that would be non-invasive but allow for easy detection of any spoof.  Another option is some border effect that takes a few pixels.  But I bet more novice users would still fall for it.

At a bare minimum, I'd suggest a pref to completely disable the ability for those who don't want to risk it.
Comment 67 Zack Weinberg (:zwol) 2011-08-10 11:15:25 PDT
http://mayscript.com/blog/eric/browser-ui-spoofing-attack-revisited is very relevant.  I'm with Jesse: we don't want this feature.
Comment 68 Kai Engert (:kaie) 2011-08-10 12:40:42 PDT
I think a web page should never be able to pop up to full screen.
Comment 69 Chris Pearce (:cpearce) 2011-08-10 15:41:49 PDT
(In reply to Kai Engert (:kaie) from comment #68)
> I think a web page should never be able to pop up to full screen.

The request for full-screen only works in the event handlers for user-initiated keypress or mouse click events. So a site can't just switch to full-screen whenever it wants to.

Full-screen can be disabled by a pref as well (it's off by default in the patches at the moment).

(In reply to Jesse Ruderman from comment #65)
> > Can you elaborate on why a Flash-style warning fails to mitigate the spoofing 
> > risks you describe?

If a pop-down appeared to grant/deny permission before entering full-screen then your concerns should be alleviated? Similar to how a pop-down appears to grant/deny popups. Then the user will be aware they're entering full-screen mode, as they have to consciously confirm it. This pop-down can make them aware that they can exit by pressing escape.


> > We should minimize the risk here, but this feature is needed.
> 
> I'm not convinced this feature is needed.

It's wanted for HTML5 games, as well as video players.

However games are rather limited by not being able to receive all key input. Most modern games require a plethora of hot keys. Maybe what games are really looking for is a way to trap mouse input inside the window? It's pretty much impossible to write good FPS controls without mouse input captured.
Comment 70 Chris Pearce (:cpearce) 2011-08-10 20:20:40 PDT
(In reply to Dão Gottwald [:dao] from comment #64)
> (In reply to Chris Pearce [:cpearce] from comment #63)
> > > > > You're querying the chrome document here, though.
> > > > 
> > > > Dão: When a dom document is in full-screen state, all ancestor documents are
> > > > in full-screen state as well, including the ancestor chrome document.
> > > 
> > > And this is going to work with separate chrome/content processes?
> > 
> > Currently this won't work with separate chrome/content processes, but we'll
> > make this work cross-process in a follow up bug.
> 
> What exactly is that followup work going to involve? Do you have a concrete
> plan?

We'll need to proxy requests to nsGlobalWindow::SetFullScreen() from content to the chrome process using IPC. While handling the request on the chrome side we'd need to set the mozFullScreen state in the chrome document.
Comment 71 Chris Pearce (:cpearce) 2011-08-10 20:24:12 PDT
Created attachment 552291 [details] [diff] [review]
Patch 1 v2: dom/content changes for full-screen api

Reworked to include bz's feedback:
* Moved setup of full-screen-api.enabled pref cache to nsContentUtils::Init().
* Removed document state (I'll add an event state to track the -moz-full-screen elements in patch 2).
Comment 72 Chris Pearce (:cpearce) 2011-08-10 20:27:05 PDT
Created attachment 552292 [details] [diff] [review]
Patch 2 v2: -moz-full-screen CSS pseudo class

Changed to store -moz-full-screen state in an event state instead of relying on a document state.
Comment 73 Chris Pearce (:cpearce) 2011-08-10 20:30:56 PDT
Created attachment 552294 [details] [diff] [review]
Patch 3 v1: dom mozfullscreenchange event

Rebased on top of bz's changes from bug 675405, and review comments addressed. We now dispatch a mozfullscreenchange event when we enter or leave DOM full-screen mode.

Carrying forward r=smaug.
Comment 74 Chris Pearce (:cpearce) 2011-08-10 20:37:21 PDT
Created attachment 552297 [details] [diff] [review]
Patch 5 v1: -moz-full-screen media query

Implement -moz-full-screen media query.
Comment 75 Chris Pearce (:cpearce) 2011-08-10 20:40:58 PDT
Created attachment 552298 [details] [diff] [review]
Patch 7 v2: mochitests

Updated to reflect fullscreenchange event being renamed to mozfullscreenchange.
Comment 76 Boris Zbarsky [:bz] (still a bit busy) 2011-08-10 20:42:19 PDT
Comment on attachment 552292 [details] [diff] [review]
Patch 2 v2: -moz-full-screen CSS pseudo class

This looks fine with 3 nits:

1)  I'd prefer "border: none" for the iframe style.
2)  Probably safer to use "*|*:-moz-full-screen" for the style in ua.css
3)  The ua.css style should move to before the comment about xml parse errors.

r=me with those addressed.
Comment 77 Chris Pearce (:cpearce) 2011-08-10 20:44:56 PDT
Created attachment 552299 [details] [diff] [review]
Patch 8 v1: Only grant full-screen requests in trusted contexts

* Restrict requests to element.mozFullScreen() so that they're only granted in trusted contexts (in mouse or key event handlers).
* Update tests.
Comment 78 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-10 20:57:11 PDT
(In reply to Chris Pearce [:cpearce] from comment #69)
> However games are rather limited by not being able to receive all key input.
> Most modern games require a plethora of hot keys. Maybe what games are
> really looking for is a way to trap mouse input inside the window? It's
> pretty much impossible to write good FPS controls without mouse input
> captured.

They are looking for a "mouse lock" feature as well, but it's mostly a separate issue.

(In reply to Jesse Ruderman from comment #65)
> * User might not be looking at the screen.

The user wouldn't be sending input events without looking at the screen, surely.

> * Site site might add visual distractions during the transition. I saw a
> demo where a bunch of similarly-styled messaged appeared at once; the chance
> of someone reading the one saying "Press Esc to exit full screen mode"
> seemed low.

That can be avoided by making the transition to full-screen a smooth "zoom out" so the message does not overlap the Web content until the end of the transition.

> * Site might make it seem as if the "Press Esc to exit full screen mode" is
> part of an image (e.g. a banner ad or instructional screenshot) rather than
> something the browser is saying right now.

Sounds a bit far-fetched, but we can avoid this by putting the message over the browser chrome, as you suggest.

> * Site might fake the opposite transition, as if the video finished and
> exited full screen mode, leaving the user believing they are no longer in
> full screen mode.
> * Even after seeing the "Press Esc to exit full screen mode" message, the
> illusion may be strong enough on its own to convince the user they are not
> in full screen mode.

If a page goes full-screen then either the user didn't want it to, or they did. If they didn't, and we ensure the "Press Esc" message is visible, I'm confident they'll immediately exit full-screen and these issues will not apply. So the threat here would be some Web site that actually offers a desirable full-screen service but later tries to abuse full-screen status. But such threats are just as valid if we offer a "full-screen" button in the browser UI. Heck, it's almost as valid in Firefox today, if the Web page encourages the user to press F11 to go full-screen.

I don't see any way to avoid problems like that except by showing some site identification on the screen whenever the user is providing input. Perhaps we could show a URL-bar overlay at the top of the screen for a few seconds after each input event.
Comment 79 [Baboo] 2011-08-11 01:38:37 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #78)
> The user wouldn't be sending input events without looking at the screen, surely.

"Take the new blind-writing challenge! Can you write your name without looking?" ;-)

But now in all seriousness, what about delaying the switch from full-screen after the input event?
Comment 80 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-11 03:27:47 PDT
Comment on attachment 552299 [details] [diff] [review]
Patch 8 v1: Only grant full-screen requests in trusted contexts


> NS_IMETHODIMP
> nsDocument::MozCancelFullScreen()
> {
>   if (!nsContentUtils::IsFullScreenApiEnabled() ||
>+      !nsContentUtils::IsRequestFullScreenAllowed() ||
>       !IsFullScreenDoc() ||
>       !GetWindow())
>     return NS_OK;
What is the reason for this restriction?
Either remove this, or explain why it is needed.
In latter case, add also a comment to the code.


>+function setRequireTrustedContext(value) {
>+  netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
>+  var ps = Components.classes["@mozilla.org/preferences-service;1"]
>+                     .getService(Components.interfaces.nsIPrefBranch);
>+  // Request full-screen from a non trusted context (this script isn't a user
>+  // generated event!). We should not receive a "fullscreenchange" event.
>+  ps.setBoolPref("full-screen-api.allow-trusted-requests-only", value);
>+}
netscape.security.PrivilegeManager shouldn't be used in mochitests.
Use SpecialPowers.get/setBoolPref
https://developer.mozilla.org/en/SpecialPowers


Those addressed, r=me
Comment 81 Boris Zbarsky [:bz] (still a bit busy) 2011-08-11 10:09:38 PDT
Comment on attachment 552297 [details] [diff] [review]
Patch 5 v1: -moz-full-screen media query

>+#define NS_STYLE_OFF                            0
>+#define NS_STYLE_ON                             1

NS_STYLE_FULLSCREEN_ON/OFF, please.

Also, do you need the IsFullScreenApiEnabled() check in GetFullScreen?  Seems like if that's false, IsFullScreenDoc() should always return false...

But apart from all that, wouldn't using the media query mentioned in bug bug 678173 work better here than inventing a new -moz-full-screen?  Or do we want this media query to mean something different from the view-mode case?
Comment 82 Chris Pearce (:cpearce) 2011-08-11 14:07:38 PDT
(In reply to Olli Pettay [:smaug] from comment #80)
> Comment on attachment 552299 [details] [diff] [review]
> >   if (!nsContentUtils::IsFullScreenApiEnabled() ||
> >+      !nsContentUtils::IsRequestFullScreenAllowed() ||
> >       !IsFullScreenDoc() ||
> >       !GetWindow())
> >     return NS_OK;
> What is the reason for this restriction?

It's to prevent the browser going full-screen from script without the user initiating it. This stops the full-screen from being used as popups used to be, and it also makes it harder for bad guys' script to go full-screen and spoof the browser window and some important login page, like paypal etc.

I'll add a comment to the patch.
Comment 83 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-11 19:38:13 PDT
(In reply to Boris Zbarsky (:bz) from comment #81)
> But apart from all that, wouldn't using the media query mentioned in bug bug
> 678173 work better here than inventing a new -moz-full-screen?  Or do we
> want this media query to mean something different from the view-mode case?

I think using view-mode here would make sense.
Comment 84 Chris Pearce (:cpearce) 2011-08-11 19:43:52 PDT
Comment on attachment 552297 [details] [diff] [review]
Patch 5 v1: -moz-full-screen media query

Agreed.
Comment 85 Dão Gottwald [:dao] 2011-08-12 12:16:24 PDT
Comment on attachment 550861 [details] [diff] [review]
Patch 6 v1: Don't animate toolbar hide on dom full-screen

>   _keyToggleCallback: function(aEvent)
>   {
>     // if we can use the keyboard (eg Ctrl+L or Ctrl+E) to open the toolbars, we
>     // should provide a way to collapse them too.
>     if (aEvent.keyCode == aEvent.DOM_VK_ESCAPE) {
>-      FullScreen._shouldAnimate = false;
>-      FullScreen.mouseoverToggle(false, true);
>+      if (document.mozFullScreen) {
>+        document.mozCancelFullScreen();
>+      } else {
>+        FullScreen._shouldAnimate = false;
>+        FullScreen.mouseoverToggle(false, true);
>+      }
>     }

What's the rationale for this change?
Comment 86 Chris Pearce (:cpearce) 2011-08-12 13:22:38 PDT
Dao: Exit full-screen mode when escape is pressed in DOM full-screen mode.
Comment 87 Dão Gottwald [:dao] 2011-08-12 17:35:30 PDT
Comment on attachment 550861 [details] [diff] [review]
Patch 6 v1: Don't animate toolbar hide on dom full-screen

(In reply to Chris Pearce [:cpearce] from comment #86)
> Dao: Exit full-screen mode when escape is pressed in DOM full-screen mode.

So this front-end code piece is the only part handling ESC? This seems too weak, since content scripts can consume the event before chrome code. At the very least, the event listener needs to be a capturing listener, although I'm not quite sure if that's sufficient and e10s-friendly...
Comment 88 Chris Pearce (:cpearce) 2011-08-14 16:01:20 PDT
Created attachment 553046 [details] [diff] [review]
Patch 8 v2: Only grant full-screen requests in trusted contexts

With comment added in nsGenericHTMLElement::MozRequestFullScreen() and using SpecialPowers in mochitests. Carrying forward r=smaug.
Comment 89 Jesse Ruderman 2011-08-15 08:29:05 PDT
>> * User might not be looking at the screen.
> The user wouldn't be sending input events without looking at the screen, surely.

It would help if we could guarantee the full-screening happens immediately after the input event. Bug 678994 is one problematic case. Maybe we should add a timer to the popup blocker heuristic.

>> * Site site might add visual distractions during the transition.
> That can be avoided by making the transition to full-screen a smooth "zoom out" so the message does not overlap the Web content until the end of the transition.

Sure, that will help. Especially if we make sure evil scripts can't jank the animation, e.g. by temporarily hanging the browser.

> So the threat here would be some Web site that actually offers a desirable full-screen service but later tries to abuse full-screen status. But such threats are just as valid if we offer a "full-screen" button in the browser UI. Heck, it's almost as valid in Firefox today, if the Web page encourages the user to press F11 to go full-screen.

This is a good point. I could almost imagine arguing for a no-keyboard-input version of full screen, just so users don't get accustomed to doing something dangerous every time they watch a video.
Comment 90 Jesse Ruderman 2011-08-15 08:37:23 PDT
This feature may add attack surface by turning "Firefox stops painting" bugs and "popup blocker can be bypassed" bugs into security bugs.

As I said at the end of bug 545812 comment 65, I'm not convinced this feature is needed. But it sounds like we have the scariest problems under control.
Comment 91 Jake 2011-08-18 00:11:40 PDT
(In reply to Jesse Ruderman from comment #65)
> * User might not be looking at the screen.
> 
> * Site site might add visual distractions during the transition. I saw a
> demo where a bunch of similarly-styled messaged appeared at once; the chance
> of someone reading the one saying "Press Esc to exit full screen mode"
> seemed low.
> 
> * Site might make it seem as if the "Press Esc to exit full screen mode" is
> part of an image (e.g. a banner ad or instructional screenshot) rather than
> something the browser is saying right now.
> 
> * Site might fake the opposite transition, as if the video finished and
> exited full screen mode, leaving the user believing they are no longer in
> full screen mode.
> 
> * Even after seeing the "Press Esc to exit full screen mode" message, the
> illusion may be strong enough on its own to convince the user they are not
> in full screen mode.

How about a warning bar with buttons (leave full screen and close warning button)on it?just like the pop up "warning bar", if you don't close it manually,it will appear forever, and when you hover on the button, it changes color.
Comment 92 Chris Pearce (:cpearce) 2011-08-18 21:28:48 PDT
Created attachment 554298 [details] [diff] [review]
Patch 9 v1: Restrict key input while in full-screen mode

Restrict key input while in DOM full-screen mode to non-alphanumeric keys only. This is to reduce the effectiveness of full-screen apps being able to throw up a fake login page and phish logins etc, as password can't be typed in. Input into <input> and <textarea> elements is also blocked by this.

Tests to follow in separate patch.
Comment 93 Chris Pearce (:cpearce) 2011-08-18 21:35:53 PDT
Created attachment 554299 [details] [diff] [review]
Patch 10 v1: Exit full-screen mode on escape press

Exit full-screen mode when escape key is pressed. Dao expressed concern in comment 87 that an escape key press listener in browser.js wouldn't be reliable, so implementing in gecko here.
Comment 94 Chris Pearce (:cpearce) 2011-08-18 21:37:28 PDT
Created attachment 554300 [details] [diff] [review]
Patch 11 v1: Test full-screen key event restriction and escape-key-exit

Test key input restrictions and test that pressing escape exits full-screen mode.
Comment 95 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-19 03:21:39 PDT
Comment on attachment 554298 [details] [diff] [review]
Patch 9 v1: Restrict key input while in full-screen mode


> nsresult
> nsIContent::PreHandleEvent(nsEventChainPreVisitor& aVisitor)
> {
>   //FIXME! Document how this event retargeting works, Bug 329124.
>   aVisitor.mCanHandle = PR_TRUE;
>   aVisitor.mMayHaveListenerManager = HasFlag(NODE_HAS_LISTENERMANAGER);
> 
>+  // In DOM full-screen mode, we restrict key input to non-alphanumeric
>+  // key codes to reduce the effectiveness of phishing attacks.
>+  if (IsFullScreenAndRestrictedKeyEvent(this, aVisitor.mEvent)) {
>+    aVisitor.mCanHandle = PR_FALSE;
>+    return NS_OK;
>+  }

We don't want to prevent script initiated events.
So this check should probably go to
PresShell::HandleEventInternal

What all event handling do we want to prevent?
accesskeys? "accessnumbers" (alt+<number> to activate a tab)?
Comment 96 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-19 03:34:09 PDT
Comment on attachment 554299 [details] [diff] [review]
Patch 10 v1: Exit full-screen mode on escape press


>   // In DOM full-screen mode, we restrict key input to non-alphanumeric
>   // key codes to reduce the effectiveness of phishing attacks.
>   if (IsFullScreenAndRestrictedKeyEvent(this, aVisitor.mEvent)) {
>+    int key = static_cast<const nsKeyEvent*>(aVisitor.mEvent)->keyCode;
>+    if (aVisitor.mEvent->message == NS_KEY_UP && key == NS_VK_ESCAPE) {
>+      // Exit full-screen mode when the escape key is pressed and released.
>+      // We exit full-screen on key-up rather than key-down or key-press as
>+      // key-up is the last key event in the sequence fired for a key press.
>+      // We stop blocking key events after we leave full-screen, so if we
>+      // leave full-screen on key-down or key-press, we'll fire the remaining
>+      // key events in the sequence, which may be confusing for content.
>+      NS_DispatchToCurrentThread(
>+        NS_NewRunnableMethod(GetOwnerDoc(), &nsIDocument::CancelFullScreen));
>+    }

So script initiated key event could cancel fullscreen.

Would it make sense to handle the esc key somewhere in chrome/ui level and let it to must call MozCancelFullScreen?
Comment 97 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-19 03:37:26 PDT
Comment on attachment 554300 [details] [diff] [review]
Patch 11 v1: Test full-screen key event restriction and escape-key-exit

So the test should include testing for script initiated key events and whether
those can be dispatched and handled normally.
Comment 98 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-19 04:39:50 PDT
I think probably instead of just blocking alphanumeric input, it should exit full-screen.
Comment 99 Eric Shepherd [:sheppy] 2011-08-19 09:22:24 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #98)
> I think probably instead of just blocking alphanumeric input, it should exit
> full-screen.

I'm with roc on this one; just bounce out of full screen.
Comment 100 Chris Pearce (:cpearce) 2011-08-21 15:15:00 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #98)
> I think probably instead of just blocking alphanumeric input, it should exit
> full-screen.

That sounds incredibly annoying for games; if the user presses the wrong key accidentally, they'll end up being bounced out of full-screen.
Comment 101 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-21 16:04:23 PDT
I don't think games are going to want to use the no-keys API.
Comment 102 Chris Pearce (:cpearce) 2011-08-21 17:05:33 PDT
(In reply to Olli Pettay [:smaug] from comment #96)
> Comment on attachment 554299 [details] [diff] [review]
> Patch 10 v1: Exit full-screen mode on escape press
> [...]
> 
> Would it make sense to handle the esc key somewhere in chrome/ui level and
> let it to must call MozCancelFullScreen?

Dao's comment 87 gave me the impression that putting the full-screen-exit key press handler in chrome/ui was insufficient: "content scripts can consume the event before chrome code. At the very least, the event listener needs to be a capturing listener, although I'm not quite sure if that's sufficient and e10s-friendly...".
Comment 103 Chris Pearce (:cpearce) 2011-08-21 19:04:27 PDT
(In reply to Olli Pettay [:smaug] from comment #95)
> Comment on attachment 554298 [details] [diff] [review]
> Patch 9 v1: Restrict key input while in full-screen mode
> [...]
> What all event handling do we want to prevent?

We want to prevent any events which could be used in phishing attacks. Basically anything with an alphanumeric virtual key code.

> accesskeys? "accessnumbers" (alt+<number> to activate a tab)?

Our intention is to block any event with virtual key code in the restricted ranges, and exit full-screen mode when such key events are encountered, including accesskeys and accessnumbers.

Additionally any tab-change or browser navigation will exit full-screen mode anyway, though I've not implemented this yet.
Comment 104 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-21 20:38:47 PDT
I think probably the best approach to "blocking" keyboard input is to always allow the event to be processed, but exit full-screen in cases where a forbidden key event is processed by page content.

I think we should allow ctrl-F and perhaps other chrome command keys to be processed without exiting full-screen. So I think we need to instrument key event dispatch to detect when content has "processed" the event. I think we should have some global state that indicates whether content has processed the event. We would set that when any content script event listener is called. Some native key event listeners would also need to set it, e.g. text inputs would set it when they insert text on keypress.

The previous paragraph could be treated as an enhancement, though.
Comment 105 Chris Pearce (:cpearce) 2011-08-22 16:06:53 PDT
Created attachment 554985 [details] [diff] [review]
Patch 9: Break out of full-screen mode upon non-alphanumeric key input

* Exit full-screen mode upon non-alpahnumeric input.
* Don't exit full-screen mode upon script-dispatched alphanumeric key events.
* Add tests for exiting full-screen and script-dispatched alphanumeric key events.
Comment 106 Johnny Stenback (:jst, jst@mozilla.com) 2011-08-22 16:25:01 PDT
Comment on attachment 550855 [details] [diff] [review]
Patch 4 v1: iframe.mozallowfullscreen

 nsresult nsGenericHTMLElement::MozRequestFullScreen()
 {
   if (!nsContentUtils::IsFullScreenApiEnabled())
     return NS_OK;
 
+  // Ensure that all ancestor <iframe> elements have the mozallowfullscreen
+  // boolean attribute set.
+  nsINode* node = static_cast<nsINode*>(this);
+  do {
+    nsIContent* content = static_cast<nsIContent*>(node);
+    if (content->Tag() == nsGkAtoms::iframe &&

Should we be more explicit here and check that the node is actually an HTML node too, i.e. call content->NondeInfo()->Equals(nsGkAtoms::iframe,  kNameSpaceID_XHTML)?

+        !content->HasAttr(kNameSpaceID_None, nsGkAtoms::mozallowfullscreen)) {

And is the presence of the attribute all we want to check here, should mozallowfullscreen="false" not disallow fullscreen support?
Comment 107 Chris Pearce (:cpearce) 2011-08-22 16:39:05 PDT
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #106)
> Comment on attachment 550855 [details] [diff] [review]
> Patch 4 v1: iframe.mozallowfullscreen
> [...]
> Should we be more explicit here and check that the node is actually an HTML
> node too

Sure, sounds sensible. Thanks!

> +        !content->HasAttr(kNameSpaceID_None,
> nsGkAtoms::mozallowfullscreen)) {
> 
> And is the presence of the attribute all we want to check here, should
> mozallowfullscreen="false" not disallow fullscreen support?

mozallowfullscreen is a boolean attribute, so it's considered to be "on" when present, regardless of value. I agree that mozallowfullscreen="false" turning on full-screen doesn't make sense, but that usage matches other uses of boolean attributes in HTML5. Or is the spec moving away from using boolean attributes?
Comment 108 Johnny Stenback (:jst, jst@mozilla.com) 2011-08-22 17:24:51 PDT
Comment on attachment 552291 [details] [diff] [review]
Patch 1 v2: dom/content changes for full-screen api

+PRBool nsContentUtils::IsFullScreenApiEnabled() {

Function opening '{' on its own line in this code, please. There's a number of these to fix here.

+static void VisitDocTree(nsIDocShellTreeNode* aNode, nsDocTreeVisitor* aVisitor)

Seems like this coulde be written using the existing map of sub documents (mSubDocuments) that we already have in nsDocument rather than using the docshell tree.

r- only because of the above mentioned issue, other than that this looks good, but I'd like to look through the updated patch with that fixed (or have it explained why that won't work and read through this code once more).
Comment 109 Johnny Stenback (:jst, jst@mozilla.com) 2011-08-22 17:25:43 PDT
Comment on attachment 550855 [details] [diff] [review]
Patch 4 v1: iframe.mozallowfullscreen

r=jst with the stricter iframe element check mentioned earlier.
Comment 110 Chris Pearce (:cpearce) 2011-08-22 17:35:07 PDT
Created attachment 555000 [details] [diff] [review]
Patch 4 v1: iframe.mozallowfullscreen

Patch 4 with stricter iframe element check.
Comment 111 :Ms2ger (⌚ UTC+1/+2) 2011-08-23 02:12:31 PDT
Comment on attachment 555000 [details] [diff] [review]
Patch 4 v1: iframe.mozallowfullscreen

>+    if (content->NodeInfo()->Equals(nsGkAtoms::iframe, kNameSpaceID_XHTML) &&

Please change this to content->IsHTML(nsGkAtoms::iframe)

>+        !content->HasAttr(kNameSpaceID_None, nsGkAtoms::mozallowfullscreen)) {

And I approve of boolean attributes.
Comment 112 Chris Pearce (:cpearce) 2011-08-23 21:39:02 PDT
Created attachment 555319 [details] [diff] [review]
Patch 1 v3: dom/content changes for full-screen api

With style changes and using nsIDocuments::EnumerateSubDocuments() to traverse document trees.
Comment 113 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-08-24 04:14:20 PDT
Comment on attachment 554985 [details] [diff] [review]
Patch 9: Break out of full-screen mode upon non-alphanumeric key input


>-nsDocument::MozCancelFullScreen()
>+nsDocument::MozCancelFullScreen() {
{ should be in its own line



>+  if (!nsContentUtils::IsRequestFullScreenAllowed())
>+    return NS_OK;
if (expr) {
  stmt;
}


>+        if (IsFullScreenAndRestrictedKeyEvent(mCurrentEventContent, aEvent) &&
>+            aEvent->message == NS_KEY_DOWN) {
Maybe aEvent->message == NS_KEY_DOWN first and then IsFullScreenAndRestrictedKeyEvent


Keys are pretty restricted. I wonder if we should enable more keys when a11y is active.
Comment 114 Chris Pearce (:cpearce) 2011-08-24 16:27:55 PDT
Created attachment 555587 [details] [diff] [review]
Patch 1 v4 dom/content changes for full-screen api

Olli pointed out in another patch's review that my brace style on if statements didn't always match the local convention. I also did this in this patch, so I've fixed that and am re-requesting review.
Comment 115 Chris Pearce (:cpearce) 2011-08-24 16:29:44 PDT
(In reply to Ms2ger from comment #111)
> Comment on attachment 555000 [details] [diff] [review]
> Patch 4 v1: iframe.mozallowfullscreen
> 
> >+    if (content->NodeInfo()->Equals(nsGkAtoms::iframe, kNameSpaceID_XHTML) &&
> 
> Please change this to content->IsHTML(nsGkAtoms::iframe)

AFAICT this is equivalent, so unless anyone objects I'll make this change when landing.
Comment 116 Boris Zbarsky [:bz] (still a bit busy) 2011-08-24 18:14:57 PDT
> AFAICT this is equivalent

Yeah, it is.  The IsHTML() version is preferred, generally.
Comment 117 Chris Pearce (:cpearce) 2011-08-31 21:40:57 PDT
Created attachment 557407 [details] [diff] [review]
WIP Patch: e10s support

This patch is a work-in-progress to add e10s support for the DOM full-screen API. 

It works, with the one exception that if you press F11 (which exits browser full-screen mode) while in DOM full-screen mode, the window will exit full-screen mode, but the document will remain in DOM full-screen mode, with the full-screen element taking up the entire viewable area.

This is because there's no way to get access to the corresponding PBrowserParent in C++ in the chrome process when the Xul window's full-screen mode is toggled. bz and cjones have a tentative plan to sit down and figure out how to do this, once that's done we can fix this properly.

I won't block on e10s support, we want to land the DOM full-screen API before e10s support will be turned on.
Comment 120 Chris Pearce (:cpearce) 2011-09-06 17:55:35 PDT
Additional work:
* Implement the full-screen view-mode media query (bug 678173) to apply when in browser *or* DOM full-screen mode.
* Add a pseudo-class for elements which are ancestors of the full-screen element.
* Add a style rule to set overflow-hidden on the root element when it is an ancestor of the full-screen element. Currently there's nothing hiding scroll bars on the root full-screen element.
Comment 121 Eric Shepherd [:sheppy] 2011-09-22 05:44:56 PDT
For documentation reference: http://blog.pearce.org.nz/2011/09/mozilla-full-screen-api-progress-update.html
Comment 122 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2011-10-12 12:36:34 PDT
Link to review notes https://wiki.mozilla.org/Security/Reviews/Firefox10/CodeEditor/FullScreenAPI
Comment 124 Jesse Ruderman 2011-11-10 14:26:34 PST
sheppy, I think this landed for Firefox 10 (not 9). Did I miss something?

http://blog.pearce.org.nz/2011/11/firefoxs-html-full-screen-api-enabled.html
Comment 125 Eric Shepherd [:sheppy] 2011-11-10 14:34:22 PST
It's in 9 but preffed off, which is why the doc explains how to enable it if you want to experiment with it.
Comment 126 Eric Shepherd [:sheppy] 2011-11-10 14:35:17 PST
That said, the target milestone on this bug says mozilla9, which is where I get my information from as to what release something will be in. :)
Comment 127 Jared Wein [:jaws] (please needinfo? me) 2011-11-10 14:41:02 PST
(In reply to Eric Shepherd [:sheppy] from comment #126)
> That said, the target milestone on this bug says mozilla9, which is where I
> get my information from as to what release something will be in. :)

Yeah, I think the documentation is great. Sheppy, do you think we can add a part to say that it is enabled by default in Fx10?
Comment 128 Eric Shepherd [:sheppy] 2011-11-10 14:45:08 PST
Done!
Comment 129 Chris Pearce (:cpearce) 2011-11-10 17:28:23 PST
Thanks Sheppy. I've gone through the documentation and made a few tweaks, but overall it looks great!
Comment 130 Vlad [QA] 2011-12-20 07:16:22 PST
Hi guys.

I have tested this feature on latest Aurora and I've encountered the following issues.
The test page is: http://pearce.org.nz/full-screen/
The test plan along with the testcases is: https://wiki.mozilla.org/Platform/Features/Full_Screen_APIs/TestPlan

The issues are, on MAC OS X 10.6:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111219 Firefox/10.0a2 

1. When pressing "full screen (f=toggle)" button, the page in full screen starts to flicker.
2. When pressing the "create windowed plugin" button and then the "full screen button" the page goes in full screen even though it shouldn't. 
3. When pressing the "create windowless plugin" button and then the "full screen button" the page goes in full screen even though it shouldn't. 
4. When pressing the "full screen" button and then the "create windowed plugin" button, the page doesn't exit from full screen even though it should.
5. When pressing the "full screen" button and then the "create windowless plugin" button, the page doesn't exit from full screen even though it should.
6. The "remove full screen element from doc" button doesn't work. When in full screen, when pressing this button a poem appears. Is this intended?
7. The "request full screen and transplant" button does not work.

on WINDOWS 7:
Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111219 Firefox/10.0a2

1. When pressing the "create windowless plugin" button and then the "full screen button" the page goes in full screen even though it shouldn't.  
2. When pressing the "full screen" button and then the "create windowless plugin" button, the page doesn't exit from full screen even though it should.
3. The "remove full screen element from doc" button doesn't work. When in full screen, when pressing this button a poem appears. Is this intended?
4. The "request full screen and transplant" button does not work.

on WINDOWS XP
Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111219 Firefox/10.0a2

1. When pressing the "create windowless plugin" button and then the "full screen button" the page goes in full screen even though it shouldn't. 
2. When pressing the "full screen" button and then the "create windowless plugin" button, the page doesn't exit from full screen even though it should.
3. The "remove full screen element from doc" button doesn't work. When in full screen, when pressing this button a poem appears. Is this intended?
4. The "request full screen and transplant" button does not work.

on Ubuntu 11.10 x64
Mozilla/5.0 (X11; Linux x86_64; rv:10.0a2) Gecko/20111220 Firefox/10.0a2

1. When pressing the "create windowless plugin" button and then the "full screen button" the page goes in full screen even though it shouldn't.  
2. When pressing the "full screen" button and then the "create windowless plugin" button, the page doesn't exit from full screen even though it should.
3. The "remove full screen element from doc" button doesn't work. When in full screen, when pressing this button a poem appears. Is this intended?
4. The "request full screen and transplant" button does not work.

I've conducted this tests on order to signed-off this feature on Aurora.
Comment 131 Chris Pearce (:cpearce) 2011-12-20 13:09:22 PST
(In reply to Vlad [QA] from comment #130)
> Hi guys.
> 
> I have tested this feature on latest Aurora and I've encountered the
> following issues.
> The test page is: http://pearce.org.nz/full-screen/
> The test plan along with the testcases is:
> https://wiki.mozilla.org/Platform/Features/Full_Screen_APIs/TestPlan
> 
> The issues are, on MAC OS X 10.6:
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111219
> Firefox/10.0a2 
> 
> 1. When pressing "full screen (f=toggle)" button, the page in full screen
> starts to flicker.

I assume what you're referring to is covered by Bug 708174.

> 2. When pressing the "create windowed plugin" button and then the "full
> screen button" the page goes in full screen even though it shouldn't. 
> 3. When pressing the "create windowless plugin" button and then the "full
> screen button" the page goes in full screen even though it shouldn't. 
> 4. When pressing the "full screen" button and then the "create windowed
> plugin" button, the page doesn't exit from full screen even though it should.
> 5. When pressing the "full screen" button and then the "create windowless
> plugin" button, the page doesn't exit from full screen even though it should.

Windowed plugins do not cause full-screen requests to be denied and do not cause full-screen to exit on MacOSX.

> 6. The "remove full screen element from doc" button doesn't work. When in
> full screen, when pressing this button a poem appears. Is this intended?

When in full-screen, pressing the "remove full screen element from doc" should cause full-screen to exit and should cause the poem to appear.

> 7. The "request full screen and transplant" button does not work.

This is expected behaviour on all platforms.


> on WINDOWS 7:
> Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111219 Firefox/10.0a2
> 
> 1. When pressing the "create windowless plugin" button and then the "full
> screen button" the page goes in full screen even though it shouldn't.  

This is expected behaviour on all platforms.

> 2. When pressing the "full screen" button and then the "create windowless
> plugin" button, the page doesn't exit from full screen even though it should.

This is expected behaviour on all platforms.

> 3. The "remove full screen element from doc" button doesn't work. When in
> full screen, when pressing this button a poem appears. Is this intended?

When in full-screen, pressing the "remove full screen element from doc" should cause full-screen to exit and should cause the poem to appear.

This is expected behaviour on all platforms.


> 4. The "request full screen and transplant" button does not work.

This is expected behaviour on all platforms.


> on WINDOWS XP
> Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111219 Firefox/10.0a2
> 
> 1. When pressing the "create windowless plugin" button and then the "full
> screen button" the page goes in full screen even though it shouldn't. 
> 2. When pressing the "full screen" button and then the "create windowless
> plugin" button, the page doesn't exit from full screen even though it should.
> 3. The "remove full screen element from doc" button doesn't work. When in
> full screen, when pressing this button a poem appears. Is this intended?
> 4. The "request full screen and transplant" button does not work.

This is expected behaviour on all platforms.


> 
> on Ubuntu 11.10 x64
> Mozilla/5.0 (X11; Linux x86_64; rv:10.0a2) Gecko/20111220 Firefox/10.0a2
> 
> 1. When pressing the "create windowless plugin" button and then the "full
> screen button" the page goes in full screen even though it shouldn't.  
> 2. When pressing the "full screen" button and then the "create windowless
> plugin" button, the page doesn't exit from full screen even though it should.
> 3. The "remove full screen element from doc" button doesn't work. When in
> full screen, when pressing this button a poem appears. Is this intended?
> 4. The "request full screen and transplant" button does not work.


This is expected behaviour on all platforms.
Comment 132 Paul Silaghi, QA [:pauly] 2011-12-23 04:05:15 PST
(In reply to Chris Pearce (:cpearce) (Away until Jan 4 NZST) from comment #131)

> > 4. The "request full screen and transplant" button does not work.
> 
> This is expected behaviour on all platforms.

What if I press on "Request fullscreen" button on the red div first, and then "Request fullscreen and transplant" ? The page doesn't exit from fullscreen mode.
Comment 133 Chris Pearce (:cpearce) 2011-12-23 11:07:21 PST
Requesting full-screen while in full-screen mode should not exit full-screen, even if the new request is denied.
Comment 134 Paul Silaghi, QA [:pauly] 2012-01-11 06:23:19 PST
Hi Chris,

What about if activate general full screen in Firefox (F11 key), then enter DOM full screen and then exit DOM full screen? General full screen is not active anymore. There is a different behavior if trying with youtube full screen for example instead of DOM full screen.

Related issue here:
https://bugzilla.mozilla.org/show_bug.cgi?id=701251#c9
Comment 135 Jesse Ruderman 2013-01-14 00:42:45 PST
*** Bug 527471 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.