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.

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

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

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

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

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

Adding back needinfo, still waiting for the test.

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

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

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

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

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.

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

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

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

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

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

Still digging into the regression range. Chris - Any ideas on what's failing?

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

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

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.

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.

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

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

based on comment 20 and 21, minusing.

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.

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

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

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

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