As can be seen in the demo at http://robnyman.github.com/fullscreen/index-high-content.html, scrolling doesn't work in fullscreen in Firefox. Is it an intentional choice related to security, or a bug?

This *was* intentional, but the draft fullscreen spec has changed to move away from hiding scroll bars and preventing scrolling, so now we're non-conformant.

Thanks for the comment, Chris. So I assume we plan to change this in Firefox now then?

Yeah, we will change to allow fullscreen content to be scrolled.

Great, thank you!

Blocking. Chris, can you look into fixing this?

So... Rob Nyman's testcase here requests fullscreen on document.documentElement. Chrome shows scroll bars, Firefox does not. However if you request fullscreen in Firefox on an overflow:auto div, you *do* get scrollbars. It looks to me like we keep our scrollbars on the parent iframe (try loading an iframe with/without overflow:hidden), whereas it appears Webkit keeps its scrollbars on document.documentElement, which is why Webkit shows scrollbars on Rob N's testcase and we do not, and which is also why requesting fullscreen on document.body in Chrome *doesn't* show scrollbars. Cross-browser testcase I used to figure this out at: http://people.mozilla.org/~cpearce/synth-fullscreen.html Having thought about it more, I don't think that we should enforce that fullscreen content's overflow is *always* scrollable. I think we should keep the current behaviour that by default fullscreen content doesn't have an enforced overflow style, and allow authors to set overflow styles to allow scrolling if desired. The fullscreen spec doesn't mention scrolling at all, so I assume that we should just not force scrollbars/overflow on or off, and allow authors to use css overflow styles to do what they want. And FWIW Chrome's behaviour seems to match that, modulo showing scrollbars on documentElements rather than on iframes as we do. So there's two questions: 1. Are people ok with :fullscreen content not having overflow:auto applied? Authors can still set overflow:auto on fullscreen content to get scroll bars if they want. 2. Do we want to do anything here to match behaviour with Chrome regarding scrollbars on fullscreen document.documentElement, i.e. do we want to ensure that when authors request fullscreen on document.documentElement they get scrollbars?

I believe that what it comes down to is two main things: - What do web developers expect? I've had a number of people reporting this as a bug, since they can't see why the overflow state/behavior should change if they go into fullscreen. If they want to turn off scrollbars in fullscreen, they can do that with overflow: hidden, like for any other element. - If the user chooses View > Full Screen the scrollbars will still be there. But, if it was triggered programmatically from JavaScript, they won't be. I think that's an unnecessary inconsistency.

(In reply to Robert Nyman from comment #9) > I believe that what it comes down to is two main things: > > - What do web developers expect? I've had a number of people reporting this > as a bug, since they can't see why the overflow state/behavior should change > if they go into fullscreen. If they want to turn off scrollbars in > fullscreen, they can do that with overflow: hidden, like for any other > element. > What are they requesting fullscreen on? A document element or something contained inside a document? Maybe our documentation needs to change. > - If the user chooses View > Full Screen the scrollbars will still be there. > But, if it was triggered programmatically from JavaScript, they won't be. I > think that's an unnecessary inconsistency. View > Full Screen and the HTML fullscreen API handle different use cases. The fullscreen API makes an *element* fullscreen, whereas View > Full Screen makes the *window* fullscreen, and the window contains the document, hence the scrollbars. If you make some arbitrary canvas, image, or video fullscreen inside the page, I don't think it makes sense to have overflow scrolling on by default. For divs and other HTML elements I can see why in some cases you would and in some cases you wouldn't want overflow scrolling on when requesting fullscreen. We don't really want to be special casing these, authors can turn on overflow scrolling if they need to. For document.documentElement's going fullscreen I can appreciate the argument that it's intuitive to show scrollbars. But I can also appreciate the opposing argument that it's the containing iframe that has the document's scrollbars...

> What are they requesting fullscreen on? A document element or something > contained inside a document? > > Maybe our documentation needs to change. Well, it depends. I think it needs to be consistent, though - no matter how well we document it, most developers will go on intuition/what they believe will happen. > View > Full Screen and the HTML fullscreen API handle different use cases. > The fullscreen API makes an *element* fullscreen, whereas View > Full Screen > makes the *window* fullscreen, and the window contains the document, hence > the scrollbars. Fair point, but from a user perspective, if a web site is fullscreen, it's fullscreen. They if they can't scroll if it was done through JavaScript (and the web dev didn't take the extra overflow measure) they will blame Firefox for not working, perhaps the web site etc. > If you make some arbitrary canvas, image, or video fullscreen inside the > page, I don't think it makes sense to have overflow scrolling on by default. > For divs and other HTML elements I can see why in some cases you would and > in some cases you wouldn't want overflow scrolling on when requesting > fullscreen. We don't really want to be special casing these, authors can > turn on overflow scrolling if they need to. I think my main point here, though, is that if the element has overflow:auto in its normal state, it should be the same when it has requested to be fullscreen.

(In reply to Robert Nyman from comment #11) > > View > Full Screen and the HTML fullscreen API handle different use cases. > > The fullscreen API makes an *element* fullscreen, whereas View > Full Screen > > makes the *window* fullscreen, and the window contains the document, hence > > the scrollbars. > > Fair point, but from a user perspective, if a web site is fullscreen, it's > fullscreen. They if they can't scroll if it was done through JavaScript (and > the web dev didn't take the extra overflow measure) they will blame Firefox > for not working, perhaps the web site etc. Right. This is an argument in favour of us not hiding the scrollbars of the frame that contains the element that requested fullscreen, when the element that requested fullscreen in the documentElement. I think this is a reasonable change to make. > I think my main point here, though, is that if the element has overflow:auto > in its normal state, it should be the same when it has requested to be > fullscreen. This is reasonable. Overflow state shouldn't be affected by fullscreen. This is what happens currently, it's just that when you request fullscreen on a documentElement you're requesting fullscreen on something that isn't overflow:auto, so you don't get scrollbars. The scrollbars are on the frame containing the document (the browser chrome), and currently we hide all containing frames' scrollbars. We can opt to not hide the scrollbars of the direct containing frame in the case of documentElement requesting fullscreen.

Ah, I understand. Thanks for clarifying! So, well, personally I'd opt for not hiding the scrollbars then, but rather leave it up to the developer if they want to do that.

The scrollbars are not part of the IFRAME, they're on the viewport of the contained document.

What we do (and what the spec says) when the root element goes fullscreen is easy to describe in CSS terms: the UA style sheet makes the element position:fixed. You can't use the viewport scrollbars to scroll the contents of position:fixed elements into view --- they're position:fixed, so they won't move --- so we don't take position:fixed elements into account when we decide what's scrollable with the viewport scrollbars. This testcase shows that. Firefox, Chrome and IE all behave the same way and don't show scrollbars on the root element when it's position:fixed, even if its contents overflow the viewport. So I think what we do when the root element goes fullscreen is what the CSS and fullscreen specs currently require. I don't know why Chrome is drawing a scrollbar in the fullscreen testcase but not in this testcase.

From a CSS perspective, sure. But from a developer perspective, I feel fairly certain that a majority will expect the content to be scrollable in fullscreen if it was in normal view.

OK, but we have to find a way to meet those expectations in a way that makes sense in CSS, rather than descend into DWIM randomness.

One option would be to simply have the *|*:fullscreen rule also be :not(:root), so none of those changes are applied when the root element is the fullscreen element. This would need to be changed in the spec as well of course.

Yes, that could be an option.

Started a thread on public-webapps to discuss standardizing Roc's suggested change: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0710.html

Will be interesting to see any potential feedback on that.

There was no outcry on the public-webapps thread, so lets do this.

We noticed that sometimes Facebook's image fullscreen feature leaves the browser scrollbar visible, and this patch seems to stop that happening, so I'd like to get this patch on Aurora so we can fix this bug sooner. I'll request approval after this has been on central for a few days...

This works fine on Android and Desktop, but FF OS...ran into problems. Issues I hit include: When I select fullscreen on http://pearce.org.nz/fullscreen/, the blue div appears to be on-top always and it's scrollable. This is differing behavior than what's seen on desktop and android, as on desktop/android, the red div is scrollable, the blue div is not. FF OS instead always keeps the blue div partially rendered on top in fullscreen, even when it's scrolled. This makes it impossible to view all of the possible elements on the page. Chris - Thoughts? Shall I file a followup bug for this?

(In reply to Jason Smith [:jsmith] from comment #27) > Chris - Thoughts? Shall I file a followup bug for this? Fullscreen is only scrollable when its requested on document.documentElement. My test page at http://pearce.org.nz/fullscreen/ does not request fullscreen on document.documentElement, that's why it's not scrollable. The blue div at http://pearce.org.nz/fullscreen/ is not scrollable when fullscreen in the b2g desktop client browser or as a web app for me using the b2g desktop client. I updated yesterday. When did you last update? My other test page at http://people.mozilla.org/~cpearce/synth-fullscreen.html has a button to request fullscreen on document.documentElement, and also has the option to request fullscreen on a div with scrollbars too.

(In reply to Chris Pearce (:cpearce) from comment #28) > (In reply to Jason Smith [:jsmith] from comment #27) > > Chris - Thoughts? Shall I file a followup bug for this? > > Fullscreen is only scrollable when its requested on > document.documentElement. My test page at http://pearce.org.nz/fullscreen/ > does not request fullscreen on document.documentElement, that's why it's not > scrollable. > > The blue div at http://pearce.org.nz/fullscreen/ is not scrollable when > fullscreen in the b2g desktop client browser or as a web app for me using > the b2g desktop client. I updated yesterday. When did you last update? I'm on today's build (9/12) testing on the Otoro phone. I know the blue div isn't intended to be scrollable (which is what I saw on desktop/android), but that's not what I'm seeing on FF OS on device. I'll get a video shortly that will probably better describe this.

http://www.youtube.com/watch?v=Ho6dWOqdTys <-- video demonstrating the problem. Does that provide clarity?

(In reply to Jason Smith [:jsmith] from comment #29) > I'm on today's build (9/12) testing on the Otoro phone. WiFi works for you on the Otoro device? Did you have to do something special, or did it just start working yesterday? I haven't had Wifi working for weeks on my Otoro. > I know the blue div > isn't intended to be scrollable (which is what I saw on desktop/android), > but that's not what I'm seeing on FF OS on device. I'll get a video shortly > that will probably better describe this. That does indeed sound like incorrect behaviour. I'm updating my repo now, and will test with soon... (In reply to Jason Smith [:jsmith] from comment #30) > http://www.youtube.com/watch?v=Ho6dWOqdTys <-- video demonstrating the > problem. Does that provide clarity? Hmmm, that video didn't load for me. It's not my day today... ;)

(In reply to Chris Pearce (:cpearce) from comment #31) > (In reply to Jason Smith [:jsmith] from comment #29) > > I'm on today's build (9/12) testing on the Otoro phone. > > WiFi works for you on the Otoro device? Did you have to do something > special, or did it just start working yesterday? I haven't had Wifi working > for weeks on my Otoro. Hmm, strange. It works for me when I connect to mozilla guest and mozilla g in mountain view, although I know some people have had problems - https://github.com/mozilla-b2g/gaia/issues/4662 being one example. I'd file a bug on the wifi issue if it isn't working for you (I'd imagine there's probably cases where diff > > > I know the blue div > > isn't intended to be scrollable (which is what I saw on desktop/android), > > but that's not what I'm seeing on FF OS on device. I'll get a video shortly > > that will probably better describe this. > > That does indeed sound like incorrect behaviour. I'm updating my repo now, > and will test with soon... > > > (In reply to Jason Smith [:jsmith] from comment #30) > > http://www.youtube.com/watch?v=Ho6dWOqdTys <-- video demonstrating the > > problem. Does that provide clarity? > > Hmmm, that video didn't load for me. It's not my day today... ;) How about this link? http://dl.dropbox.com/u/1827165/VID_20120912_174035.mp4

OK, I was able to reproduce this bounce back problem on my colleague's Otoro. Please file a new bug on this and I'll look at it once I get my wifi fixed.

(In reply to Chris Pearce (:cpearce) from comment #33) > OK, I was able to reproduce this bounce back problem on my colleague's > Otoro. Please file a new bug on this and I'll look at it once I get my wifi > fixed. Sounds good. I filed bug 790850 on this.

> WiFi works for you on the Otoro device? Did you have to do something > special, or did it just start working yesterday? I haven't had Wifi working > for weeks on my Otoro. You could be unlucky and have a GB version, i.e. not the version with the ICS kernel. That's unfortunately the one I got sent to me (and you can't flash the kernel yourself). Then you need to install the special GB builds, that might not be supported much longer.

Comment on attachment 659601 [details] [diff] [review] Patch: add not root to :-moz-full-screen [Approval Request Comment] Bug caused by (feature/regressing bug #): Not a regression. User impact if declined: There's a bug in, or tickled by, Facebook's image fullscreen feature that this patch fixes; if a Facebook user user fullscreen's a photo, sometimes a scrollbar appears at the right of the fullscreened photo. This patch fixes that bug. Since Facebook is so popular, we'd like to get this patch on Aurora so the fix can get to users quicker. Testing completed (on m-c, etc.): This has been on m-c since 9 September PDT, no regressions spotted yet. Risk to taking this patch (and alternatives if risky): Pretty low risk, it's a CSS change. String or UUID changes made by this patch: None.

Fixed in Firefox 17 release train: https://hg.mozilla.org/releases/mozilla-aurora/rev/8061df55a71d

I can verify the bug is fixed. Using Win 7 64-bit and today's Aurora build.

Verified on the latest beta on Windows 7 64bit, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 , Build ID: 20121023124120

Verified on Firefox 18 beta 1, both on Windows 7 32-bit and Windows 7 64-bit. User Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121121075611 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121121075611

The bug still exists in Android for Firefox version 20. Device: ConCorde tab 9.7 IPS Android: 4.0.4 (Icecream Sandwich)

(In reply to dragon from comment #41) > The bug still exists in Android for Firefox version 20. > Device: ConCorde tab 9.7 IPS > Android: 4.0.4 (Icecream Sandwich) Can you file a new bug on this?

Added the new bug (Android for Firefox): https://bugzilla.mozilla.org/show_bug.cgi?id=859683