Do not build layers for asynchronous scrolling if element shouldn't be scrollable

VERIFIED FIXED

Status

()

VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: stechz, Assigned: stechz)

Tracking

({crash, mobile, regression})

Trunk
crash, mobile, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec2.0+)

Details

(Whiteboard: [has patch])

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Comment 1

8 years ago
Created attachment 519720 [details] [diff] [review]
Do not build layers for asynchronous scrolling if element shouldn't be scrollable
Attachment #519720 - Flags: review?(tnikkel)
(Assignee)

Updated

8 years ago
tracking-fennec: --- → ?
Assignee: nobody → ben
Blocks: 618975
Keywords: regression
screen cast of the issue http://lassey.us/moving-content.webm

this looks pretty bad and may lead to some potentially bad memory churn, marking as blocking
tracking-fennec: ? → 2.0+
Duplicate of this bug: 642200
Blocks: 563548
this patch fixes the problem in my local build
Comment on attachment 519720 [details] [diff] [review]
Do not build layers for asynchronous scrolling if element shouldn't be scrollable

I think you want the condition to be != NS_STYLE_OVERFLOW_HIDDEN as I think you want to include overflow: auto.
(Assignee)

Updated

8 years ago
Blocks: 642246
(Assignee)

Comment 6

8 years ago
Created attachment 519754 [details] [diff] [review]
Do not build layers for asynchronous scrolling if element shouldn't be scrollable

Good call.
Attachment #519754 - Flags: review?(tnikkel)
(Assignee)

Updated

8 years ago
Attachment #519720 - Attachment is obsolete: true
Attachment #519720 - Flags: review?(tnikkel)
Attachment #519754 - Flags: review?(tnikkel) → review+
(Assignee)

Comment 7

8 years ago
http://hg.mozilla.org/mozilla-central/rev/54cb5591480e
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

8 years ago
Pushed followup for now bogus assertion: http://hg.mozilla.org/mozilla-central/rev/821740bc1b4d
I am still seeing this in today's nightly build and local trunk builds on Android (but not on desktop Linux).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 642345
(Assignee)

Comment 11

8 years ago
Created attachment 520052 [details] [diff] [review]
Followup: workaround for Android compiler bug

I think I've stumbled upon my first ever compiler bug! We are seeing bogus values for result that is returned from GetScrollbarStylesFromFrame. Returning the result directly inside the conditional fixes the problem for me. Can others verify?
Comment on attachment 520052 [details] [diff] [review]
Followup: workaround for Android compiler bug

This fixes the bug for me, in my local Android opt build.
this also fixes the problem for me
Without this patch I get a reproducible OOM crash on multiple pages.  For example:
1. Open http://demos.mozilla.org
2. Pinch zoom in as far as possible on the "sliding cards"
3. Pan left and right.

This results in an OOM content-process crash that also leaves the browser unable to pan until it is force-killed.

The followup patch fixes this.
Keywords: crash
Keywords: mobile
Whiteboard: [has patch]
Attachment #520052 - Flags: review?(tnikkel)
Attachment #520052 - Flags: review?(tnikkel) → review+
verified FIXED on builds:
    Mozilla/5.0 (Android; Linux armv7l; rv:2.1) Gecko/20110318 Firefox/4.0b13pre Fennec/4.0 ID:20110318114419
Status: RESOLVED → VERIFIED
(In reply to comment #4)
> this patch fixes the problem in my local build

verified FIXED with the use case mentioned in comment #4 as well.
Blocks: 790624
You need to log in before you can comment on or make changes to this bug.