1162648 - [Browser] Zooming in on a Browser webpage breaks the scrollbars, causing them to appear in the middle of the page

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Joshua Mitchell (Inactive)]

Description:
When user is importing contacts through Outlook, if they zoom in on the page, which is necessary as the page starts very zoomed out and small, the scrollbars may appear in the middle of the page instead of along the perimeter of the page


Repro Steps:
1) Update a Flame to 20150507064907
2) Launch Contacts
3) Select Settings
4) Select Import Contacts
5) Select Outlook
6) Zoom in on page and scroll


Actual:
Scroll bars do appear in the middle of the page


Expected:
Scrollbars will stay along the outside of the page



Environmental Variables:
Device: Flame 3.0
Build ID: 20150507064907
Gaia: 83b27f522642ea573c57e882657ab5c73d4b07f4
Gecko: 403e3c2380b5
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0




Repro frequency: 5/7

See attached: logcat video clip: https://youtu.be/_zZswq2ilRk

Comment 1

[Joshua Mitchell (Inactive)]

In Flame KK 2.2, there are no scrollbars present

so this is not a regression but a breakage of a new feature

Device: Flame 2.2 (KK - Nidghtly - Full Flash - 319mem)
Build ID: 20150506002501
Gaia: 772a9491909abd02dc67278dd453746e2dd358a8
Gecko: 3af6a0a79227
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150507_1049.txt

Comment 3

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This bug occurs on every browser webpage, which is why it can be seen on the outlook sign in page. Changing component to fit the bug better.

Updated STR:
1) Open Browser app
2) Navigate to any webpage that can bee zoomed in on
3) Zoom in> Pan the webpage

Also updating branch checks. 2.2 does have scroll bars in the browser, but this issue does not occur

Comment 4

[Yeojin Chung [:YeojinC]]

Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150505114545
Gaia: e1773d6d1014c997be4b5c4233bba3ee073b8d7b
Gecko: 510299530155
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150505123245
Gaia: e1773d6d1014c997be4b5c4233bba3ee073b8d7b
Gecko: 37a740847aed
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: e1773d6d1014c997be4b5c4233bba3ee073b8d7b
Gecko: 37a740847aed

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: e1773d6d1014c997be4b5c4233bba3ee073b8d7b
Gecko: 510299530155

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=510299530155&tochange=37a740847aed

Caused by bug 1133905

Comment 5

[KTucker [:KTucker][Inactive 3/4/2016]]

Timothy, can you take a look at this please? Looks like the landing for bug 113905 might be the cause here. We might need this backed out.

Comment 6

[Timothy Nikkel (:tnikkel)]

Sure, I can backout if I don't find a quick solution. When do we need a fix (either backout or proper fix) landed by?

Comment 7

[KTucker [:KTucker][Inactive 3/4/2016]]

It is not a smoketest blocker so the 24 hour rule does not apply in this case. Also, 2.2 is not affected so I'm guessing a fix would be fine. I am not the person to ask though.

Comment 8

[Timothy Nikkel (:tnikkel)]

(In reply to Derek Harris [:DerekH] from comment #3)
> This bug occurs on every browser webpage, which is why it can be seen on the
> outlook sign in page. Changing component to fit the bug better.
> 
> Updated STR:
> 1) Open Browser app
> 2) Navigate to any webpage that can bee zoomed in on
> 3) Zoom in> Pan the webpage
> 
> Also updating branch checks. 2.2 does have scroll bars in the browser, but
> this issue does not occur

Can you provide some sites on which you are seeing this in the browser? I can reproduce with the steps in comment 0, but haven't found a site in the browser that shows the problem yet.

Comment 9

[Timothy Nikkel (:tnikkel)]

I was able to reproduce exactly once with the STR in comment 0, and once in the browser on m.reddit.com, but doing it again has been a challenge. More reproducible steps would be helpful.

Comment 10

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

(In reply to Timothy Nikkel (:tn) from comment #9)
> I was able to reproduce exactly once with the STR in comment 0, and once in
> the browser on m.reddit.com, but doing it again has been a challenge. More
> reproducible steps would be helpful.

It seems as though this issue isnt occuring on all browser pages anymore, but I am able to reproduce this bug 10/10 times with the STR from comment 0 that leads to the outlook login page from importing contacts.

Comment 11

[Timothy Nikkel (:tnikkel)]

I am able to reproduce this now, but it takes many tries at the outlook import steps.

It seems like the resolution is going wrong. When there is no bug the resolution at max zoom is ~5. When the bug appears the max zoom resolution is ~3.7. The resolution at other zooms also appears wrong.

Comment 12

[Timothy Nikkel (:tnikkel)]

So the problem is that in APZCCallbackHelper::UpdateRootFrame when we call ScrollFrame that can cause us to flush layout (for example bug 898871). We do that after we set the new scroll position clamping scroll port rect, but before we set the new resolution. So we reflow the scroll frame (SetScrollPositionClampingScrollPortSize marks it dirty) with the new scroll position clamping scroll port rect but the old resolution. We don't reflow on resolution changes.

This also has the bad property that the scroll call happens it will try to align the scroll position with layer pixels, but its looking at the existing resolution on the layers (from the last paint). We are going to invalidate that when we set a new resolution.

Comment 13

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Comment 14

[Botond Ballo [:botond]]

Comment on attachment 8605073 [details] [diff] [review]
patch

Review of attachment 8605073 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, but I'd like Kats to have a look as well, because I know there were some subtleties to the order of operations here.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8605073 [details] [diff] [review]
patch

Review of attachment 8605073 [details] [diff] [review]:
-----------------------------------------------------------------

This seems fine, I looked through the history and it was just always this way but there wasn't any particular reason for it. It's important that the scrollPositionClampingScrollPortSize gets set before the scroll position and this doesn't change that, so it should be fine.

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e0231e8d2cdf

Comment 17

[Timothy Nikkel (:tnikkel)]

(In reply to Timothy Nikkel (:tn) from comment #12)
> This also has the bad property that the scroll call happens it will try to
> align the scroll position with layer pixels, but its looking at the existing
> resolution on the layers (from the last paint). We are going to invalidate
> that when we set a new resolution.

I filed this as bug 1164652.

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/e0231e8d2cdf

Comment 19

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue is verified fixed on the latest Nightly Flame 2.5 build.

Actual Results:  The scroll bars were always on the edge of the screen.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150709010204
Gaia: fc6643dd3da2ccdf2ab284479643836bb3698644
Gecko: f34a7120f46b
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0