Open Bug 1531474 Opened 6 years ago Updated 2 years ago

Allow immediate handoff from "whole page" div to <html> if <html> is only scrollable when zoomed in

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Version:
67 Branch
Platform:
All
Android
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: csheany, Unassigned)

References

Details

Attachments

(4 files)

Screenshot_20190305-185239.jpg
196.22 KB, image/jpeg
Details
Screenshot_20190306-221600.jpg
223.49 KB, image/jpeg
Details
Screenshot_20190306-221654.jpg
232.82 KB, image/jpeg
Details
Screenshot_20190311-162548.jpg
298.28 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:67.0) Gecko/67.0 Firefox/67.0

Steps to reproduce:

  1. Open this bug
  2. Zoom in
  3. Scroll

Actual results:

The page gets stuck

Expected results:

To be determined

Component: General → Panning and Zooming
OS: Unspecified → Android
Product: Firefox for Android → Core
Hardware: Unspecified → All
Version: Firefox 67 → 67 Branch

Botond, would you mind taking a look?

Flags: needinfo?(botond)

We don't do scroll handoff by design on Android. So when you reach the end of the scrollable div it won't hand off to scrolling the visual viewport around.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(botond)
Resolution: --- → INVALID

Thank you for your response.

Would you mind elaborating?

This seems like a regression.

If it's a regression please use mozregression to find the regressing changeset.

It seems to depend on page/ element length.

Should it always happen at the same point?

Are there consequences to enabling the pref?

(In reply to csheany from comment #0)

Actual results:

The page gets stuck

I assume you mean it gets stuck until you lift your finger. With the next gesture, you should be able to continue scrolling to the end.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #2)

We don't do scroll handoff by design on Android.

(To be more precise, we don't do "immediate" scroll handoff, that is handoff within the same gesture.)

So when you reach the end of the scrollable div it won't hand off to scrolling the visual viewport around.

(Until you lift your finger and start a new gesture.)

(In reply to csheany from comment #6)

It seems to depend on page/ element length.

Right, if a bug page is short enough to fit completely onto the screen when zoomed out, the <div> on the page is not scrollable, and the only thing that ever scrolls is the viewport (so there is no handoff).

Are there consequences to enabling the pref?

Which pref?

Perhaps we could heuristically detect cases where a scrollable <div> is the main scrollable element on a page, and allow immediate handoff from it to the viewport?

Though I seem to recall people saying this kind of page structure is an anti-pattern. Not sure whether that's still the accepted wisdom.

Kohei, can you remind me why Bugzilla uses this kind of page structure (instead of making the <html> itself scrollable, and using position:fixed for the header)?

This is mainly because we are migrating to an app-ish framing UI that can be seen on Slack, Facebook Messenger, etc. Currently only the header is fixed, but 2-column layout is on the way. FYI, Google News uses the same page structure.

And we are planning a minimum mobile/tablet optimization work later this year.

See Also: → 1503643

Ok, fair enough.

I'm going to reopen this bug to track the suggestion from comment 8:

Perhaps we could heuristically detect cases where a scrollable <div> is the main scrollable element on a page, and allow immediate handoff from it to the viewport?

Randall, Snorp, as you were the drivers behind the "no immediate handoff on Android" change, can you comment on whether this sounds reasonable to you?

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: Scrolling pauses on Bugzilla → Allow immediate handoff from "whole page" div to viewport if viewport is only scrollable when zoomed in

To catch up...

The page does not fit the screen when zoomed out.

The pref I was referring to was apz.allow_immediate_handoff.

In the screenshot, the green rectangle does not account for the rest of the page (regression?)

Dragging my finger just before that point is when scrolling breaks.

(In reply to csheany from comment #12)

The pref I was referring to was apz.allow_immediate_handoff.

Yes, setting that pref to true should allow you to scroll the entire page without a pause / having to lift your finger. I just checked and it does for me.

And the screenshot?

I think that is the issue here.

Flags: needinfo?(botond)

Each scrollable element gets its own minimap. The one shown in the screenshot is the one for the <html> element (which is the only one for which the blue (visual) and red (layout) viewports can be different).

If you scroll around to where the origin of the scrollable <div> is, I expect you'll find the <div>'s minimap.

That said, there is something unexpected about the minimap shown in the screenshot: I would expect the green area to be no larger than the red (that is, the <html> element shouldn't have a layout scroll range). Leaving needinfo on me to investigate that.

Before you say I am not sure what the screenshot is intedned to illustrate... :)

The viewports of each element in this case happen to have the same with which may have caused confusion.

Also, scrolling is smooth past the point at which the page initially loads so I am not sure if your theory is correct.
.
Maybe the summary should be edited to reflect that.

This clarification might make it easier to track down the regression.

Maybe immediate handofff could be reinvestigated though as the behavior is an improvement.

I still don't quite understand scrollable <div> but that is another story. :)

An example of a paged with a "fixed" length where the issue still occurs...

https://bugzilla.mozilla.org/describecomponents.cgi?full=1

Botond, were you thinking this was Bug 1523329 with a different format?

(In reply to Botond Ballo [:botond] from comment #15)

That said, there is something unexpected about the minimap shown in the screenshot: I would expect the green area to be no larger than the red (that is, the <html> element shouldn't have a layout scroll range). Leaving needinfo on me to investigate that.

After taking a closer look, I realized the screenshot actually shows both minimaps superimposed. The larger green area belongs to the <div>. So nothing unexpected there.

Flags: needinfo?(botond)

(In reply to csheany from comment #21)

Botond, were you thinking this was Bug 1523329 with a different format?

No relation. Bug 1523329 was about not being able to scroll at all. Here, you can scroll, you just need to lift your finger for the scroll to transfer from one scrollable element to another.

(In reply to csheany from comment #19)

I still don't quite understand scrollable <div> but that is another story. :)

By "scrollable <div>" I just mean an element on the page other than the root (<html> element) which is scrollable. Such elements are commonly <div>s but don't have to be. In Bugzilla, most of the page (everything except the fixed header) is taken up by a scrollable <div>. This is why we have the handoff issue when zoomed in - there are two scrollable elements, the <html> and the <div>.

needinfo for comment 11

Flags: needinfo?(snorp)
Flags: needinfo?(rbarker)

I just meant that the page fit the screen and wasn't scrollable upon loading.

What I am noticing is that the page thinks it reached the bottom before actually doing so.

Before getting them involved, should we make sure that we are on the same "page"?

I think a few details are being overlooked.

Flags: needinfo?(botond)

@csheany Can you find the same issue on any other site? If not, I’d suggest closing this bug as WONTFIX. I guess Bugzilla is a very special case; we have fixed the header with CSS Flexbox (a modern technique) but never officially supported mobile and tablet devices. I really don’t want to waste Firefox developer resources here (/me looks botond) especially because we’re planning a mobile optimization later this year, as I said earlier.

I’d say, as early as Q2.

I'm not sure which other sites have the same format.

It seems like a browser issue as it doesn't happen on every page

It would be nice to get fixed I just think at the might the focus is on the wrong aspect.

At some point with enough comments this page might no longer have an issue which is why I posted the example in Comment 20.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #29)

Can you find the same issue on any other site?

Any site whose main scrollable element is not the <html> element is going to be affected.

For example, Google News (which you mentioned earlier) has the same issue if you check "Always enable zoom".

(In reply to csheany from comment #28)

Before getting them involved, should we make sure that we are on the same "page"?

I think a few details are being overlooked.

I haven't seen anything so far to indicate that the diagnosis in comment 7 is wrong.

If you believe it is, can you explain why?

Flags: needinfo?(botond)

In the second sceenshot the bottom of the page is not view but the issue still occurs.

As menitoned in Comment 18 scrolling is smooth past the point which is.

Why isn't the green area capturing the entire <div>?

(In reply to csheany from comment #34)

In the second sceenshot the bottom of the page is not view but the issue still occurs.

The issue is going to occur on any Bugzilla page where the entire page doesn't fit onto the screen on load.

Why isn't the green area capturing the entire <div>?

The green area in that screenshot does represent the entire <div>.

Something is getting lost in translation.

The summary says "if viewport is only scrollable when zoomed in" but the viewport is scrollable when zoomed out.

Comment 7 and Comment 35 seem to conflict with each other.

(In reply to csheany from comment #36)

Something is getting lost in translation.

The summary says "if viewport is only scrollable when zoomed in" but the viewport is scrollable when zoomed out.

Ok, I understand the confusion now.

First, as "viewport" is an overloaded term, let me clarify that in this context by "viewport" I meant the <html> element. (I edited the bug summary accordingly.)

On Bugzilla, the <html> is only ever scrollable when zoomed in. If the page is scrollable when zoomed out, the (only) thing that's scrolling is the <div>.

The issue occurs when both the <div> and the <html> are scrollable (otherwise, there is no "handoff").

The "if <html> is only scrollable when zoomed in" in the bug title does not refer to the conditions that trigger this bug, but rather a limitation on the solution I'm proposing: I'm proposing to allow immediate handoff from the <div> to the <html>, but limited to cases where the <html> is only scrollable when zoomed in. (Allowing immediate handoff from a <div> to the <html> in general would defeat the original intent behind disallowing immediate handoff on Android (bug 1230552).)

Summary: Allow immediate handoff from "whole page" div to viewport if viewport is only scrollable when zoomed in → Allow immediate handoff from "whole page" div to <html> if <html> is only scrollable when zoomed in

(In reply to csheany from comment #37)

Comment 7 and Comment 35 seem to conflict with each other.

I don't think so.

(In reply to Botond Ballo [:botond] from comment #7)

Right, if a bug page is short enough to fit completely onto the screen when zoomed out, the <div> on the page is not scrollable, and the only thing that ever scrolls is the viewport (so there is no handoff).

page fits completely onto screen when zoomed out (indicating <div> is not scrollable) ==> issue does not occur

(In reply to Botond Ballo [:botond] from comment #35)

The issue is going to occur on any Bugzilla page where the entire page doesn't fit onto the screen on load.

page does not fit onto screen when zoomed out (indicating <div> is scrollable) ==> issue occurs

I'm not sure which parts of the page are which but I still think the issue is the green rectangle stopping short.

That is what's unexpected.

(In reply to csheany from comment #40)

I'm not sure which parts of the page are which but I still think the issue is the green rectangle stopping short.

That is what's unexpected.

Stopping short of what? If you mean that the minimap as a whole isn't as tall as the screen, that's just how we size the minimap for a page of these dimensions. We try to keep the minimap's aspect ratio matching that of the page, but there is also a limit on the width, so doesn't obscure too much of the page. In this case, the width limit prevails, and to maintain aspect ratio the minimap is shorter than the screen.

Actual results:

Blue line... yellow line... green line

Expected results:

Blue line

Yellow line

Green line

(In reply to csheany from comment #42)

Expected results:

Blue line

Yellow line

Green line

Are we looking at the same screenshot (https://bugzilla.mozilla.org/attachment.cgi?id=9049065)? Because that is what I see.

(In reply to Botond Ballo [:botond] from comment #43)

Are we looking at the same screenshot (https://bugzilla.mozilla.org/attachment.cgi?id=9049065)? Because that is what I see.

Oh, I think I know what you're talking about. You're looking at this screenshot (https://bug1531474.bmoattachments.org/attachment.cgi?id=9049066), and wondering why the div's minimap shows us being all the way at the bottom, when the content we're seeing is not in fact at the bottom of the page.

The reason for this is the nested scrolling on the page. The div is indeed scrolled to its bottom, but the div's "viewport" (the blue rect on the div's minimap) is larger than the screen. The div's blue rect corresponds roughly to the <html>'s red rect (modulo the fixed header), and within that we are scrolled to the top.

Would you mind explaining the nested scrolling part a little more?

IIRC, the handoff change was done in bug 1230552, which was about flings in a subframe being handed off to the parent, resulting in a bad experience.

Flags: needinfo?(snorp)

(In reply to csheany from comment #46)

Would you mind explaining the nested scrolling part a little more?

I would be happy to, but this is getting off-topic for Bugzilla. Please find me in the #apz channel on the Mozilla IRC and ask there.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #47)

IIRC, the handoff change was done in bug 1230552, which was about flings in a subframe being handed off to the parent, resulting in a bad experience.

Yep, that's right.

Here, I'm proposing that we relax that restriction a bit, and allow immediate handoff in a specific set of cases: pages like Bugzilla that have a "full-page" div that that's scrollable, and where handoff only occurs because zooming in can make the <html> scrollable as well. I was wondering if you think that's reasonable.

Flags: needinfo?(rbarker)

For the question in comment 49

Flags: needinfo?(snorp)

(In reply to Botond Ballo [:botond] from comment #49)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #47)

IIRC, the handoff change was done in bug 1230552, which was about flings in a subframe being handed off to the parent, resulting in a bad experience.

Yep, that's right.

Here, I'm proposing that we relax that restriction a bit, and allow immediate handoff in a specific set of cases: pages like Bugzilla that have a "full-page" div that that's scrollable, and where handoff only occurs because zooming in can make the <html> scrollable as well. I was wondering if you think that's reasonable.

That seems reasonable.

Flags: needinfo?(snorp)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: