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

RESOLVED INVALID

Status

()

RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: jsmith, Unassigned)

Tracking

({regression, testcase})

Trunk
B2G C4 (2jan on)
ARM
Gonk (Firefox OS)
regression, testcase
Points:
---

Firefox Tracking Flags

(blocking-basecamp:-)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

6 years ago
I thought this was fixed, apparently not. Original bug was a blocker too.
Blocks: 779286
blocking-basecamp: --- → ?
(Reporter)

Updated

6 years ago
Keywords: regression

Comment 2

6 years ago
roc, do you think you can find an owner for this?
Assignee: nobody → roc
blocking-basecamp: ? → +
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?
Flags: needinfo?(jsmith)
(Reporter)

Comment 5

6 years ago
(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.
Flags: needinfo?(jsmith)
Keywords: qawanted
QA Contact: jsmith

Updated

6 years ago
Target Milestone: --- → B2G C4 (2jan on)

Comment 6

6 years ago
Adding back needinfo, still waiting for the test.
Flags: needinfo?(jsmith)
(Reporter)

Comment 7

6 years ago
(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.
Flags: needinfo?(jsmith)
Keywords: qawanted
(Reporter)

Comment 8

6 years ago
(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?
Keywords: regressionwindow-wanted
(Reporter)

Comment 10

6 years ago
(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.
Summary: Cannot scroll web content in fullscreen mode in a hosted app requested on the entire HTML body → Cannot scroll web content in fullscreen mode in a hosted app and browser requested on the entire HTML body
(Reporter)

Updated

6 years ago
Keywords: qawanted
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.
Flags: needinfo?(jsmith)
(Reporter)

Comment 12

6 years ago
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
Flags: needinfo?(jsmith)
(Reporter)

Comment 13

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

Comment 14

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

Comment 15

6 years ago
Regression Range:

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

Comment 16

6 years ago
I'll dig into a bit more later, but I think I can already confirm this definitely broke a while back.
(Reporter)

Comment 17

6 years ago
Still digging into the regression range.

Chris - Any ideas on what's failing?
Flags: needinfo?(cpearce)
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.
(Reporter)

Updated

6 years ago
Flags: needinfo?(cpearce)
Created attachment 699686 [details]
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.
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.
blocking-basecamp: + → ?
(Reporter)

Comment 22

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

Comment 23

6 years ago
Removing qawanted & regressionwindow-wanted - we've got a testcase to go off of now.
Keywords: qawanted, regressionwindow-wanted → testcase
based on comment 20 and 21, minusing.
Assignee: ajones → nobody
blocking-basecamp: ? → -
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
(Reporter)

Comment 27

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

Comment 29

6 years ago
Okay, fair enough. Makes sense. I'll close the bug then.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.