The default bug view has changed. See this FAQ.

Some parts of page scroll at different rates in Fennec

VERIFIED FIXED in Firefox 6

Status

()

Core
Graphics
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: mbrubeck, Assigned: stechz)

Tracking

({mobile, regression})

Trunk
mozilla7
mobile, regression
Points:
---

Firefox Tracking Flags

(firefox5 unaffected, firefox6- fixed, firefox7 fixed, fennec6+)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
1. Open http://tbpl.mozilla.org/?tree=Firefox in Fennec and wait for it to finish loading.
2. Scroll the page.

Results: In my Android opt build, some parts of the content scroll normally, while others stay fixed at first and then "catch up" with the others after a delay.  (On another page where I saw this, the text scrolled normally but backgrounds lagged behind.)

In my desktop Linux debug build, I get a content process crash:

###!!! ABORT: nsDisplayScrollLayer should always be defined: 'hasCount', file /home/mbrubeck/src/mozilla/mozilla-central/layout/base/nsDisplayList.cpp, line 1938
(Assignee)

Updated

6 years ago
Assignee: nobody → ben
(Assignee)

Comment 1

6 years ago
Thanks to Roc for helping me find this problem. When sets are finally merged into a stacking context, there is a particular expected ordering. First come borders and backgrounds, then negative z-index, etc. See:

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#1542

Since I was putting the info display item in Content(), it was possible for scroll layers to be put below info layers, which violates an important invariant!
(Assignee)

Comment 2

6 years ago
Created attachment 531483 [details] [diff] [review]
Some parts of page scroll at different rates in Fennec
Attachment #531483 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Depends on: 647192
(Assignee)

Comment 3

6 years ago
Try build started here: http://tbpl.mozilla.org/?tree=Try&rev=50815fe4496e
Is this a regression from bug 647192? In that case it should block that bug.
(Assignee)

Comment 5

6 years ago
Not a regression, but the reftest relies on the added displayport stuff from bug 647192.
(Assignee)

Updated

6 years ago
Keywords: regressionwindow-wanted
Comment on attachment 531483 [details] [diff] [review]
Some parts of page scroll at different rates in Fennec

Review of attachment 531483 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #531483 - Flags: review?(roc) → review+
(Assignee)

Updated

6 years ago
Duplicate of this bug: 656416
tracking-fennec: ? → 6+
(Reporter)

Updated

6 years ago
status-firefox5: --- → unaffected
(Assignee)

Updated

6 years ago
Duplicate of this bug: 658315
Duplicate of this bug: 659891
(Reporter)

Comment 10

6 years ago
Is this ready to land on mozilla-central?   Is it safe to request approval to land this in Aurora for Firefox 6?
Status: NEW → ASSIGNED
(Reporter)

Comment 11

6 years ago
Requesting tracking-firefox6.  This is a user-visible regression from Fennec 5 to Fennec 6.
status-firefox6: --- → affected
status-firefox7: --- → affected
tracking-firefox6: --- → ?
(Assignee)

Comment 12

6 years ago
Sorry, this went off my radar. This needs another try run. I was having reftest issues but I think the FF5 regression fix might have taken care of the orange.
(Assignee)

Comment 13

6 years ago
Still seems to have an orange, sadly: http://tbpl.mozilla.org/?tree=Try&rev=af7f094914ab
tracking-firefox6: ? → -
(Assignee)

Comment 14

6 years ago
Fixed reftest for orange by disabling reftest for non-remote run.

Pushed to inbound http://hg.mozilla.org/integration/mozilla-inbound/rev/c64dcd99b27e
(Reporter)

Comment 15

6 years ago
http://hg.mozilla.org/mozilla-central/rev/c64dcd99b27e
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
(Reporter)

Comment 16

6 years ago
Comment on attachment 531483 [details] [diff] [review]
Some parts of page scroll at different rates in Fennec

Requesting approval-mozilla-aurora.  One-line change to fix a regression from Fx5 -> Fx6 that breaks some web pages in Fennec.  This patch has been in nightlies for the past week with no adverse effect on desktop or mobile.
Attachment #531483 - Flags: approval-mozilla-aurora?
(Reporter)

Updated

6 years ago
status-firefox7: affected → fixed
Attachment #531483 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to comment #16)
> Comment on attachment 531483 [details] [diff] [review] [review]
> Some parts of page scroll at different rates in Fennec
> 
> Requesting approval-mozilla-aurora.  One-line change to fix a regression
> from Fx5 -> Fx6 that breaks some web pages in Fennec.  This patch has been
> in nightlies for the past week with no adverse effect on desktop or mobile.

(Aside: this is basically the perfect nomination comment)
http://hg.mozilla.org/releases/mozilla-aurora/rev/034d91c4d1fc
status-firefox6: affected → fixed

Comment 19

6 years ago
I can still reproduce this issue following steps from bug 656041 which is duplicate of this, on Aurora build:
Mozilla /5.0 (Android;Linux armv7l;rv:6.0a2) Gecko/20110629 Firefox/6.0a2 Fennec/6.0a2
device: LG Optimus 2X (Android 2.2)

Comment 20

6 years ago
Bug 658315, sorry.

Comment 21

6 years ago
Still reproducible on Firefox 6 Beta 2: 
Mozilla /5.0 (Android;Linux armv7l;rv:6.0) Gecko/20110713 Firefox/6.0 Fennec/6.0 
following the steps from bug 658315. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 22

6 years ago
Part of the problem of bug 658315 was fixed by this bug, but looking at the screenshot for bug 658315 shows that 658315 is not a duplicate of this bug. This is my error; I just saw the crash stack and assumed that it was the same problem.

Closing this bug and re-opening the dupe.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 23

6 years ago
Verified fixed on Firefox 6 Beta 2: Mozilla /5.0 (Android;Linux armv7l;rv:6.0) Gecko/20110713 Firefox/6.0 Fennec/6.0

Device: LG Optimus 2X (Android 2.2)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.