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

VERIFIED FIXED in Firefox 41, Firefox OS master

Status

()

Core
Layout
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Joshua Mitchell (Inactive), Assigned: tnikkel)

Tracking

({regression})

unspecified
mozilla41
ARM
Gonk (Firefox OS)
regression
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.5+, firefox39 wontfix, firefox40 wontfix, firefox41 fixed, b2g-v2.2 unaffected, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing][systemsfe], URL)

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

3 years ago
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
(Reporter)

Comment 2

3 years ago
Created attachment 8602872 [details]
logcat_20150507_1049.txt
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
status-b2g-v2.2: --- → unaffected
Component: Gaia::Contacts → Gaia::Browser
Keywords: regression
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Summary: [Contacts] Zooming in on Outlook sign-in page during import process breaks the scrollbars, causing them to appear in the middle of the page → [Browser] Zooming in on a Browser webpage breaks the scrollbars, causing them to appear in the middle of the page
blocking-b2g: --- → 3.0+
Component: Gaia::Browser → Layout
Keywords: regressionwindow-wanted
Product: Firefox OS → Core
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: ychung
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
Blocks: 1133905
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
QA Contact: ychung
blocking-b2g: 3.0+ → spark+
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.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(tnikkel)
(Assignee)

Comment 6

3 years ago
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?
Flags: needinfo?(ktucker)
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.
Flags: needinfo?(ktucker)
(Assignee)

Comment 8

3 years ago
(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.
Flags: needinfo?(tnikkel) → needinfo?(dharris)
(Assignee)

Comment 9

3 years ago
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.
Flags: needinfo?(dharris) → needinfo?(tnikkel)
(Assignee)

Comment 11

3 years ago
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.
(Assignee)

Comment 12

3 years ago
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.
(Assignee)

Comment 13

3 years ago
Created attachment 8605073 [details] [diff] [review]
patch
Assignee: nobody → tnikkel
Flags: needinfo?(tnikkel)
Attachment #8605073 - Flags: review?(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.
Attachment #8605073 - Flags: review?(bugmail.mozilla)
Attachment #8605073 - Flags: review?(botond)
Attachment #8605073 - Flags: review+
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.
Attachment #8605073 - Flags: review?(bugmail.mozilla) → review+
(Assignee)

Comment 17

3 years ago
(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.
https://hg.mozilla.org/mozilla-central/rev/e0231e8d2cdf
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
blocking-b2g: spark+ → 2.5+
status-b2g-v2.5: --- → fixed
status-b2g-master: affected → fixed
status-firefox39: --- → wontfix
status-firefox40: --- → wontfix
status-b2g-v2.5: fixed → ---
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
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-master: fixed → verified
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.