Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Can't scroll content in fullscreen in Firefox

VERIFIED FIXED in Firefox 17

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: Robert Nyman, Assigned: cpearce)

Tracking

Trunk
mozilla18
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+, firefox17 verified, firefox18 verified)

Details

(Whiteboard: [WebAPI:P0] [testday 20121005])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
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?

Comment 1

5 years ago
Created attachment 647683 [details]
reduced html

Updated

5 years ago
Blocks: 545812
Component: General → General
OS: Mac OS X → All
Product: Firefox → Core
Version: 17 Branch → Trunk
(Assignee)

Comment 2

5 years ago
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.
(Reporter)

Comment 3

5 years ago
Thanks for the comment, Chris. So I assume we plan to change this in Firefox now then?
(Assignee)

Comment 4

5 years ago
Yeah, we will change to allow fullscreen content to be scrolled.
(Reporter)

Comment 5

5 years ago
Great, thank you!
(Assignee)

Updated

5 years ago
Duplicate of this bug: 786766

Updated

5 years ago
blocking-basecamp: --- → ?
Blocking. Chris, can you look into fixing this?
Assignee: nobody → cpearce
blocking-basecamp: ? → +
(Assignee)

Comment 8

5 years ago
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?
(Reporter)

Comment 9

5 years ago
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.
(Assignee)

Comment 10

5 years ago
(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...
(Reporter)

Comment 11

5 years ago
> 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.
(Assignee)

Comment 12

5 years ago
(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.
Assignee: cpearce → nobody
Component: General → DOM: Core & HTML
(Reporter)

Comment 13

5 years ago
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.
Created attachment 658426 [details]
fixed-pos testcase

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.
(Reporter)

Comment 16

5 years ago
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.
(Reporter)

Comment 19

5 years ago
Yes, that could be an option.
Assignee: nobody → cpearce
Whiteboard: [WebAPI:P0]
(Assignee)

Comment 20

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

Comment 21

5 years ago
Will be interesting to see any potential feedback on that.
(Assignee)

Comment 22

5 years ago
Created attachment 659601 [details] [diff] [review]
Patch: add not root to :-moz-full-screen

There was no outcry on the public-webapps thread, so lets do this.
Attachment #659601 - Flags: review?(roc)
Attachment #659601 - Flags: review?(roc) → review+
(Assignee)

Comment 23

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d329814112b4
(Assignee)

Comment 24

5 years ago
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...
https://hg.mozilla.org/mozilla-central/rev/d329814112b4
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

5 years ago
Keywords: verifyme
QA Contact: jsmith

Updated

5 years ago
Duplicate of this bug: 788383
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?
Keywords: verifyme

Updated

5 years ago
Whiteboard: [WebAPI:P0] → [WebAPI:P0], [qa verification failed]
(Assignee)

Comment 28

5 years ago
(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?
(Assignee)

Comment 31

5 years ago
(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
(Assignee)

Comment 33

5 years ago
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.
(Reporter)

Comment 35

5 years ago
> 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.
(Assignee)

Comment 36

5 years ago
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.
Attachment #659601 - Flags: approval-mozilla-aurora?
Attachment #659601 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox17: --- → affected
status-firefox18: --- → fixed
(Assignee)

Comment 37

5 years ago
Fixed in Firefox 17 release train:
https://hg.mozilla.org/releases/mozilla-aurora/rev/8061df55a71d
status-firefox17: affected → fixed
I can verify the bug is fixed.
Using Win 7 64-bit and today's Aurora build.
Whiteboard: [WebAPI:P0], [qa verification failed] → [WebAPI:P0], [qa verification failed], [testday 20121005]

Updated

5 years ago
Whiteboard: [WebAPI:P0], [qa verification failed], [testday 20121005] → [WebAPI:P0] [testday 20121005]
Keywords: verifyme

Updated

5 years ago
QA Contact: jsmith

Updated

5 years ago
status-firefox17: fixed → verified
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
status-firefox18: fixed → verified

Updated

5 years ago
Status: RESOLVED → VERIFIED
Keywords: verifyme

Updated

5 years ago
QA Contact: manuela.muntean

Updated

5 years ago
Depends on: 824699

Updated

5 years ago
Depends on: 824702

Comment 41

4 years ago
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?

Comment 43

4 years ago
Added the new bug (Android for Firefox):
https://bugzilla.mozilla.org/show_bug.cgi?id=859683
You need to log in before you can comment on or make changes to this bug.