Closed Bug 1258843 Opened 8 years ago Closed 8 years ago

[e10s] Graphical corruption (large black or white areas, or pieces of background tab), with SVG & Shopify Dashboard

Categories

(Core :: Layout, defect)

x86_64
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
e10s m9+ ---
firefox46 --- unaffected
firefox47 + fixed
firefox48 --- verified

People

(Reporter: ben, Assigned: mattwoodrow)

References

()

Details

(Keywords: regression, testcase)

Attachments

(6 files)

What did you do?
================
1. Using Shopify dashboard in Firefox Developer Edition

What happened?
==============
A large, black or white block appears, obstructing the view of parts of the page. The block is related to an SVG in a nav menu, but does not appear in regular Firefox.

What should have happened?
==========================
The block shouldn't be there.

Is there anything else we should know?
======================================
I've reduced the html as much as I can get away with at work. I marked the relevant code with "<!--HERE-->" in the HTML. There are two sections.
The error is only in Firefox Developer Edition. The relevant two sections of code are marked "<!--HERE-->" in the HTML.
Keywords: testcase
OS: Other → Mac OS X
Product: Mozilla Developer Network → Firefox
Hardware: All → x86_64
Version: unspecified → 47 Branch
I can reproduce in current Nightly on Linux. The black or white area looks like graphical corruption to me.

I'll see if I can track down a regression range...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Mac OS X → All
Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c525c5164cdde373a636d525e53c77f52d8fd693&tochange=c99e8abb5e00eaa439a3be7864df0e4135326349

--> Regression from Bug 1221842 or Bug 1231538.

Matt, mind taking a look?
Component: General → Layout
Flags: needinfo?(matt.woodrow)
Product: Firefox → Core
Version: 47 Branch → Trunk
Summary: SVG-related display error → Graphical corruption (large black or white areas that change with window-resizing), with SVG & Shopify Dashboard
Whiteboard: [specification][type:bug]
Here's a screenshot after I opened a new tab & switched back to the testcase. As you can see, pieces of the new tab are displayed in the graphical corruption.
[Tracking Requested - why for this release]: Serious graphical regression (potentially showing pieces of background tabs superimposed over current tab, as shown in screenshot 2)
Summary: Graphical corruption (large black or white areas that change with window-resizing), with SVG & Shopify Dashboard → Graphical corruption (large black or white areas, or pieces of background tab), with SVG & Shopify Dashboard
Attachment #8733561 - Attachment description: Shopify.html → testcase 1 (from reporter) (try resizing your browser if you don't immediately see the issue)
Somewhat good news: this seems to be e10s-specific.  (If I disable multi-process support in Firefox Preferences, this bug goes away.)
tracking-e10s: --- → ?
Attachment #8733587 - Attachment description: testcase 2 (reduced) → testcase 2 (reduced): only gray/yellow should be visible, after 100ms
Summary: Graphical corruption (large black or white areas, or pieces of background tab), with SVG & Shopify Dashboard → [e10s] Graphical corruption (large black or white areas, or pieces of background tab), with SVG & Shopify Dashboard
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
We were building SVG display items (and reporting them as opaque) even though painting of them did nothing (since the ::PaintSVG function returned immediately if visibility was hidden).

My patch changed the layerization, and made this testcase end up with a layer with only the svg content in it.

Given that the content was opaque we weren't clearing the layer buffer (expecting the content to cover it all), so you could end up with either the previous content, or possibly uninitialized memory.
Attachment #8733665 - Flags: review?(dholbert)
Comment on attachment 8733665 [details] [diff] [review]
Don't build SVG display items if they aren't going to paint anything

Review of attachment 8733665 [details] [diff] [review]:
-----------------------------------------------------------------

r=me on the fix -- thanks!
Attachment #8733665 - Flags: review?(dholbert) → review+
Tomcat, why did you back this out?

Matt, are you working on resolving this?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(cbook)
Flags: needinfo?(matt.woodrow)
https://hg.mozilla.org/mozilla-central/rev/2344e8a7c4b7
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Matt, should this fix be uplifted to Aurora 47 in preparation for our e10s experiments on Beta 47?
Flags: needinfo?(matt.woodrow)
Comment on attachment 8733665 [details] [diff] [review]
Don't build SVG display items if they aren't going to paint anything

Approval Request Comment
[Feature/regressing bug #]: Long standing bug, but made more common with Bug 1231538 
[User impact if declined]: Unitialized memory shown when visibility:hidden set on SVG content.
[Describe test coverage new/current, TreeHerder]: Tested manually.
[Risks and why]: Very low risk.
[String/UUID change made/needed]: None.
Flags: needinfo?(matt.woodrow)
Attachment #8733665 - Flags: approval-mozilla-aurora?
Ben, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(ben)
Comment on attachment 8733665 [details] [diff] [review]
Don't build SVG display items if they aren't going to paint anything

recent regression in e10s mode, Aurora47+
Attachment #8733665 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I can verify that it's fixed -- no issues when resizing attached testcase in latest Nightly (48.0a1 (2016-04-11)).

(As a sanity-check, I also confirmed that I can still reproduce the bug using a build from just before the fix landed).
Status: RESOLVED → VERIFIED
Flags: needinfo?(ben)
(In reply to Daniel Holbert [:dholbert] from comment #24)
> I can verify that it's fixed -- no issues when resizing attached testcase in
> latest Nightly (48.0a1 (2016-04-11)).
> 
> (As a sanity-check, I also confirmed that I can still reproduce the bug
> using a build from just before the fix landed).

That's great! Thanks.
(In reply to Ritu Kothari (:ritu) from comment #22)
> Ben, could you please verify this issue is fixed as expected on a latest
> Nightly build? Thanks!

Looks good to me. Thanks, people!
You need to log in before you can comment on or make changes to this bug.