824699 - Cannot scroll web content in fullscreen mode in a hosted app and browser requested on the entire HTML body

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Jason Smith [:jsmith]]

Build: B2G 18 12/26/2012
Device: Unagi

Steps:

1. Install the "Hosted App Test Case 1" on http://jds2501.github.com/webapi-permissions-tests/
2. Launch the app
3. Select Fullscreen Mode
4. Try scrolling the content

Expected:

The content should be scrollable.

Actual:

The content isn't scrollable.

Additional Notes:

The browser also has a different issue that I thought was fixed - see the associated bug with that one as well.

Comment 1

[Jason Smith [:jsmith]]

I thought this was fixed, apparently not. Original bug was a blocker too.

Comment 2

[Doug Turner (:dougt)]

roc, do you think you can find an owner for this?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is this a recent regression?  Like perhaps from bug 824007?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this still a problem in builds with the patch for bug 824917 in them?

Comment 5

[Jason Smith [:jsmith]]

(In reply to Boris Zbarsky (:bz) from comment #4)
> Is this still a problem in builds with the patch for bug 824917 in them?

I'll retest with that patch after the next build shows up with that patch included.

Comment 6

[JP Rosevear [:jpr]]

Adding back needinfo, still waiting for the test.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #5)
> (In reply to Boris Zbarsky (:bz) from comment #4)
> > Is this still a problem in builds with the patch for bug 824917 in them?
> 
> I'll retest with that patch after the next build shows up with that patch
> included.

Yes, it's still a problem. I can reproduce this bug with the 1/3/2012 build.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #5)
> > (In reply to Boris Zbarsky (:bz) from comment #4)
> > > Is this still a problem in builds with the patch for bug 824917 in them?
> > 
> > I'll retest with that patch after the next build shows up with that patch
> > included.
> 
> Yes, it's still a problem. I can reproduce this bug with the 1/3/2012 build.

Meant to say 1/3/2013 build.

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK.  In that case, can someone hunt down the regression range?

Comment 10

[Jason Smith [:jsmith]]

(In reply to Boris Zbarsky (:bz) from comment #9)
> OK.  In that case, can someone hunt down the regression range?

Yeah I can look into this.

Interestingly enough, now this bug reproduces in the browser as well. It didn't before however - before we were getting extreme bounce back behavior on scrolling.

Comment 11

[Andrew Overholt [:overholt]]

FWIW I can reproduce this with transit directions in the Maps app on a 2013-01-06 build.

I'm going to put this in needinfo on Jason since he's working on getting the regression range.

Comment 12

[Jason Smith [:jsmith]]

Digging into the regression range right now. I also reproduce what Andrew describes as well - which implies this bug might also be happening not in fullscreen.

So far I've got:

12/13/2012 - Working
12/26/2012 - Busted
1/6/2013 - Busted

Comment 13

[Jason Smith [:jsmith]]

Actually, it looks like the bug in fullscreen is *different* than the bug being seen here. I just confirmed this bug happens on the 12/20 build with fullscreen but does *not* happen with Andrew's test case. New bug incoming.

Regression Range:

12/13/2012 - ?
12/20/2012 - Busted
12/26/2012 - Busted
1/6/2013 - Busted

Comment 14

[Jason Smith [:jsmith]]

Looks like this was busted on 12/13/2012 as well. Screwed up my test earlier on. Updated:

12/13/2012 - Busted
12/20/2012 - Busted
12/26/2012 - Busted
1/6/2013 - Busted

Comment 15

[Jason Smith [:jsmith]]

Regression Range:

11/1/2012 - Busted
12/13/2012 - Busted
12/20/2012 - Busted
12/26/2012 - Busted
1/6/2013 - Busted

Comment 16

[Jason Smith [:jsmith]]

I'll dig into a bit more later, but I think I can already confirm this definitely broke a while back.

Comment 17

[Jason Smith [:jsmith]]

Still digging into the regression range.

Chris - Any ideas on what's failing?

Comment 18

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I'm pretty sure this is a BrowserElementScrolling.js bug.

Comment 19

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Vivien Nicolas (:vingtetun) from comment #18)
> I'm pretty sure this is a BrowserElementScrolling.js bug.

When the application is not using fullscreen then BrowserElementScrolling.js works by returning the element to scroll because scrollMaxY is not 0 at http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementScrolling.js#330.

When the application is using fullscreen this value is equal to 0 and so it does not work. Not sure why it is 0, still looking.

Comment 20

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Testcase

Actually I'm not sure this is a bug. I can reproduce the exact same behavior in Firefox with the attached testcase where I can not scroll anymore.

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I'm tempted to resolve this as WONTFIX if someone can confirm that it is the right behavior on Firefox desktop. Also I don't think we will block the release for this since Firefox has shipped with such a behavior already and people can workaround it pretty easily.

Renominating for now to let triage take a decision.

Comment 22

[Jason Smith [:jsmith]]

(In reply to Vivien Nicolas (:vingtetun) from comment #21)
> I'm tempted to resolve this as WONTFIX if someone can confirm that it is the
> right behavior on Firefox desktop. Also I don't think we will block the
> release for this since Firefox has shipped with such a behavior already and
> people can workaround it pretty easily.
> 
> Renominating for now to let triage take a decision.

Desktop originally had this behavior before bug 779286 landed. When bug 779286 landed, we added the ability to scroll web content in fullscreen.

Not surprised though this reproduces on desktop too.

Comment 23

[Jason Smith [:jsmith]]

Removing qawanted & regressionwindow-wanted - we've got a testcase to go off of now.

Comment 24

[Doug Turner (:dougt)]

based on comment 20 and 21, minusing.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Jason: It appears that we've fixed this partially on desktop. But the testcase from vivien shows the same behavior on Firefox desktop as well.

Comment 26

[Chris Pearce [:cpearce (Not reading bugmail)]]

Are you requesting fullscreen on the body element? The body element is not supposed to be made scrollable when it enters fullscreen, as the scrollbars reside on one of the body element's ancestors. If you want to make a document fullscreen and keep it scrollable, request fullscreen on the document.documentElement, not on the body element.

For example, compare the behaviour of the "document.body" and "document.documentElement" buttons on this page:
http://people.mozilla.org/~cpearce/synth-fullscreen.html

Comment 27

[Jason Smith [:jsmith]]

(In reply to Chris Pearce (:cpearce) from comment #26)
> Are you requesting fullscreen on the body element? The body element is not
> supposed to be made scrollable when it enters fullscreen, as the scrollbars
> reside on one of the body element's ancestors. If you want to make a
> document fullscreen and keep it scrollable, request fullscreen on the
> document.documentElement, not on the body element.
> 
> For example, compare the behaviour of the "document.body" and
> "document.documentElement" buttons on this page:
> http://people.mozilla.org/~cpearce/synth-fullscreen.html

Yeah, I was requesting fullscreen on the body element.

I guess what my initial thought of what I was expecting was that the scrollbars would appear if the content within the DOM tree below the element where the request was made was larger than the content resolution available. I didn't actually expect this originally based on that theory - why not follow that behavior? Does the w3c spec say here?

I tested each test case on device - looks like the bug you reopened that wasn't actually a dupe is definitely happening, as I reproduce it as well with one of those test cases in that page you reference.

Comment 28

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Jason Smith [:jsmith] from comment #27)
> I guess what my initial thought of what I was expecting was that the
> scrollbars would appear if the content within the DOM tree below the element
> where the request was made was larger than the content resolution available.

I can see how you may *and* may not want overflowing fullscreen content to scroll.

You can make content that overflows scroll by adding an "overflow: auto;" style.

For example if you press the "lorem scrollbars" in my testcase above, and then click the "lorem" button you'll see the content is fullscreen and still scrollable.

> I didn't actually expect this originally based on that theory - why not
> follow that behavior?

Because the default style of the <body> element doesn't specify overflow, the scrollbars are on one of the ancestors (I can't remember which, the <html> element or its parent <iframe> maybe).

If we turn overflow scrolling on by default, then people who want it off by default will complain, so we're damned either way. ;)


> Does the w3c spec say here?

The spec says that the element which requests fullscreen gets "width: 100%; height: 100%;" styles applied, it doesn't say anything about what to do when content overflows the element's boundaries.

Comment 29

[Jason Smith [:jsmith]]

Okay, fair enough. Makes sense. I'll close the bug then.