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

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

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

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

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.

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?

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.

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

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.

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

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.

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

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

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