Closed Bug 1265256 Opened 9 years ago Closed 9 years ago

Disabling e10s causes scrolling corruption

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
48 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla49
Tracking Flags:
Tracking Status
e10s - ---
firefox47 --- unaffected
firefox48 + fixed
firefox49 + fixed

People

(Reporter: sparky, Assigned: mattwoodrow)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

Screenshot-1.png
(deleted), image/png
Details
fixed-canvas-background
(deleted), patch
mstange
: review+
lizzard
: approval-mozilla-aurora+
lizzard
: approval-mozilla-beta+
Details | Diff | Splinter Review
Attached image Screenshot-1.png (deleted) —
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160417030601 Steps to reproduce: 1. Disable multi-process Firefox 2. Visit http://queequegg.tumblr.com/ 3. Scroll Actual results: After scrolling 1 to 2 view port lengths, the page contents begins to repeat, and there is more significant corruption on the edges where the menu elements are. After scrolling far enough, portions of the layout (sometimes the entire page) go black. Expected results: Scrolling without corruption or repetition.
Component: Untriaged → Graphics
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
Nothing jumpes out from the regression range. Could you narrow it down using inbound builds?
GOOD: 20160406231745 http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1460009865/ BAD: 20160406235542 http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1460012142/ https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e8dad24cfffa9f5d8406df8c59839902cd446e65&tochange=75ea4f74e03016375ae153ae02fa2562456e4f90 Looks like 852754. Also, in the console that I run Firefox from, I see these messages when scrolling on a broken build: [GFX1-]: DrawSurface with bad surface 1 [GFX1-]: Invalid draw target(s) 0x7f782c14ece0 and 0
Blocks: 852754
Flags: needinfo?(matt.woodrow)
This is the same as bug 1263480, I'll get it landed today.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(matt.woodrow)
Resolution: --- → DUPLICATE
No longer blocks: 1265574
I can still reproduce on Latest Nightly on windows7 with HWA and e10s both disabled. https://hg.mozilla.org/mozilla-central/rev/ae7413abfa4d3954a6a4ce7c1613a7100f367f9a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160419030312
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Alice, you should reopen bug 1263480, as this one was marked as a duplicate of the other.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → DUPLICATE
No, what Alice did was correct. Bug 1263480 as filed is fixed, and it didn't end up fixing this bug, so it turns out this bug was not a duplicate.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
With the latest build, I can still reproduce this bug, but I can no longer reproduce Bug 1263480. So they're separate issues.
[Tracking Requested - why for this release]: similar to bug 1265574, this should be tracked since it's a regression.
status-firefox48: --- → affected
tracking-firefox48: --- → ?
Component: Graphics → ImageLib
Whiteboard: [gfx-noted]
Is ImageLib the correct component? The regressing bug is Graphics: Layers, and it does seem to be a layering based bug. I did some futzing around on the reported sites ( http://queequegg.tumblr.com/ and http://salamanstra.keenspot.com/ ) and found that they both have background-attachment:fixed on <body>. Setting it back to the default scroll fixed the scrolling corruption on both sites. So it definitely seems layer/layout related to me.
(In reply to Matthew Turnbull [Bluefang] from comment #10) > Is ImageLib the correct component? The regressing bug is Graphics: Layers, > and it does seem to be a layering based bug. Likely not given that bug 852754 didn't touch ImageLib code (which lives in image/). Let's just move it. I'm not certain Graphics: Layers is the correct component, but ImageLib is definitely wrong.
Component: ImageLib → Graphics: Layers
Component: Graphics: Layers → Layout
Assignee: nobody → matt.woodrow
Attached patch fixed-canvas-background (deleted) — — Splinter Review
This function used to pass (borderArea, aClipRect) into PrepareImageLayer, but the refactoring made us use the version in the nsDisplayBackgroundImage ctor which passes borderArea for both params. This was giving us the wrong computed size and we weren't drawing what we needed. I also moved the function into nsCanvasFrame since it's only needed there.
Attachment #8744166 - Flags: review?(mstange)
Attachment #8744166 - Flags: review?(mstange) → review+
This bug affects the solar-panel-monitoring UI at https://monitoring.solaredge.com/ (which has a fixed-attachment tiled background, it looks like). As I scroll, the background at the bottom of the window repaints with a somewhat-random solid color (or black, or white) instead of continuing to display the same piece of the fixed background image. I verified in a local build that the attached patch (comment 12) fixes the bug there, though.
https://hg.mozilla.org/mozilla-central/rev/bc717d405714
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Target Milestone: mozilla48 → mozilla49
Comment on attachment 8744166 [details] [diff] [review] fixed-canvas-background Approval Request Comment [Feature/regressing bug #]: Bug 852754 [User impact if declined]: Corruption with background-attachment:fixed and no h/w acceleration for layers. [Describe test coverage new/current, TreeHerder]: Manually tested. [Risks and why]: Very low risk, just reverts an incorrect piece of the original patch. [String/UUID change made/needed]: None
Attachment #8744166 - Flags: approval-mozilla-aurora?
Tracking, regression from 48. Matt do you want to uplift this? Seems likely it may fix bug 1265574 as well.
tracking-firefox48: ? → +
tracking-firefox49: --- → +
Flags: needinfo?(matt.woodrow)
I've requested uplift already.
Flags: needinfo?(matt.woodrow)
Comment on attachment 8744166 [details] [diff] [review] fixed-canvas-background Scrolling fix for non-e10s, fixes a regression Thanks Matt, not sure how I missed your earlier comment! Too-fast triage.
Attachment #8744166 - Flags: approval-mozilla-beta+
Attachment #8744166 - Flags: approval-mozilla-aurora?
Attachment #8744166 - Flags: approval-mozilla-aurora+
I'm hitting conflicts applying this to beta: grafting 342035:b503bcc0c6ef "Bug 1265256 - Use the canvas positioning area when computing the background-attachment:fixed rect for canvas frames. r=mstange a=lizzard" merging layout/base/nsDisplayList.cpp merging layout/base/nsDisplayList.h merging layout/generic/nsCanvasFrame.cpp merging layout/generic/nsCanvasFrame.h warning: conflicts while merging layout/base/nsDisplayList.cpp! (edit, then use 'hg resolve --mark') abort: unresolved conflicts, can't continue
Flags: needinfo?(matt.woodrow)
47 isn't affected by this bug, looks like I can't clear the beta approval flag though sorry.
status-firefox47: --- → unaffected
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: