Some parts of page scroll at different rates in Fennec

VERIFIED FIXED in Firefox 6

Status

()

defect
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: mbrubeck, Assigned: stechz)

Tracking

({mobile, regression})

Trunk
mozilla7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

Reporter

Description

8 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

8 years ago
Assignee: nobody → ben
Assignee

Comment 1

8 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

Updated

8 years ago
Depends on: 647192
Is this a regression from bug 647192? In that case it should block that bug.
Assignee

Comment 5

8 years ago
Not a regression, but the reftest relies on the added displayport stuff from bug 647192.
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

8 years ago
Duplicate of this bug: 656416
tracking-fennec: ? → 6+
Assignee

Updated

8 years ago
Duplicate of this bug: 658315
Duplicate of this bug: 659891
Reporter

Comment 10

8 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

8 years ago
Requesting tracking-firefox6.  This is a user-visible regression from Fennec 5 to Fennec 6.
Assignee

Comment 12

8 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

8 years ago
Still seems to have an orange, sadly: http://tbpl.mozilla.org/?tree=Try&rev=af7f094914ab
Assignee

Comment 14

8 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

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

Comment 16

8 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?
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)

Comment 19

8 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

8 years ago
Bug 658315, sorry.

Comment 21

8 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

8 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: 8 years ago8 years ago
Resolution: --- → FIXED

Comment 23

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