1296793 - [non-e10s] Top bars at SoundCloud & Yammer leave behind artifacts when it slides out of view

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Start Firefox, in a profile with e10s *disabled*.

 2. Visit https://soundcloud.com/officialfroxic

 3. Press Page-Down.
    --> Notice that a white bar pops down from the top, saying:
       Froxic                         [follow][share]

 4. Press Page-Up.


EXPECTED RESULTS:
 The bar that appeared in step 3 should cleanly animate out of view.

ACTUAL RESULTS:
 The bar leaves behind several artifacts while it slides out of view.

Comment 1

[Daniel Holbert [:dholbert]]

This bug has changed behavior twice in recent history.

* Before bug 1288244 landed, we had EXPECTED RESULTS.
* Bug 1288244's patches made this very bad - the bar leaves behind a solid black region when it animates out of view. Regression range for that change in behavior:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=204bdc8b929c88d164e165fd8f28e4c1cd002bef&tochange=7fb6f9a2d7fee76746c73fa5ba1a5c091073e199
* Bug 1284440's patches made this slightly better - now the bar leaves behind stripes of black & stripes of content-that-should-be-gone when it animates out of view.  Range for that slight improvement in behavior:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=71046967f0adda356ce78e57b54e151bf9091ccc&tochange=2ada5807b65db03b5fd51568f4cb5fa77940d990
* And that's still how it renders in current nightly.

So, this is basically a regression from bug 1288244, though it was mitigated somewhat by bug 1284440.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug in Nightly 51

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot

Comment 4

[Daniel Holbert [:dholbert]]

Note: the artifacts/corruption goes away if I focus another window or change tabs (forcing a repaint, basically, I think).  So, seems like it might be an invalidation bug, perhaps.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: about:support graphics section

My platform info:
 - I'm using Nightly 51.0a1 (2016-08-19) on Ubuntu 16.04
 - This happens with a fresh profile, with e10s disabled.
 - about:support "graphics" section attached as a text file.

Comment 6

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]: This is a visual regression in Firefox 49 (currently in beta, scheduled to go to release soon).  We'll ship this bug as a regression in Firefox 49 if we don't come up with a fix soonish.

I just verified locally that Firefox 48 release is unaffected, and that the latest Firefox 49 beta & Firefox 50 aurora builds are affected by this.

Moreover, Firefox 49 beta has the initial/worse version of this bug, with a fully-solid-black area being left behind when the top bar slides away.  (whereas aurora & nightly are a bit better, since they seem to have benefited from Bug 1284440's fix - they show artifacts instead of a fully-black area)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug in Firefox 49 beta5 (showing worse fully-black graphical corruption)

Comment 8

[Daniel Holbert [:dholbert]]

[reposting comment 1 with a bug-copypaste typo fixed, and improving the explanation a bit while I'm at it]:

This bug's symptoms have changed slightly since it first regressed. Specifically, we've had three different behaviors.

(1) Original good behavior: Before bug 1141468 landed, we had EXPECTED RESULTS.

(2) Fully-black graphical corruption behavior: Bug 1141468's patches made the top bar leave behind a solid black region when it animates out of view. Regression range for when that started happening (only containing bug 1141468):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=204bdc8b929c88d164e165fd8f28e4c1cd002bef&tochange=7fb6f9a2d7fee76746c73fa5ba1a5c091073e199
Shown in attachment 8783156 [details]

(3) Stripes-of-artifacts-and-black behavior: Bug 1284440's patches made the top bar leave behind stripes of black & stripes of content-that-should-be-gone when it animates out of view.  Range for us changing from the fully-black corruption to that behavior (only containing bug 1284440):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=71046967f0adda356ce78e57b54e151bf9091ccc&tochange=2ada5807b65db03b5fd51568f4cb5fa77940d990
Shown in attachment 8783137 [details]

So, this is basically a regression from bug 1141468, mitigated somewhat (but not really that much) by bug 1284440.

Firefox 48 has behavior (1). Firefox 49 beta5 has behavior (2). Firefox 50 aurora and 51 (current Nightly) have behavior (3).

Comment 9

[Daniel Holbert [:dholbert]]

I'm seeing this bug at Mozilla's Yammer instance, as well, actually. My STR there:
 0. Be using a build with e10s disabled. (and aside from that, a fresh profile should be fine)
 1. Visit e.g. https://www.yammer.com/mozilla.com/#/threads/company?type=general&view=all  (log in w/ Mozilla employee LDAP credentials if prompted)
 2. Press "Page down".
   --> Note that the "All Company" header bar gets shorter.

ACTUAL RESULTS: In the space that was previously occupied by the now-shorter "All Company" header bar, black stripes & artifacts of scrolled-away content are left behind.

I verified that this Yammer issue started with the same regression window here (i.e. it started when bug 1141468 landed).

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug at yammer (in a build from just after this regressed, w/ ~fully-black corruption)

Comment 11

[Daniel Holbert [:dholbert]]

Update: in the last day or so, this bug has coincidentally just been mitigated / worked-around in Nightlies via bug 594876 (turning on accelerated layers by default on Linux).

So now, to hit this bug in Nightly, you have to manually disable accelerated layers by setting about:config pref layers.acceleration.disabled to false (and also turn off e10s, as noted in comment 0).

So this is getting a bit more edge-casey on Nightly... But on 49 beta / 50 Aurora (on Linux at least; haven't tested other platforms), you simply need e10s disabled to hit this bug -- and that's still the default configuration for (I think) half of our users on those releases.

Comment 12

[Matt Woodrow (:mattwoodrow)]

Attachment: flattening-bug

I hate layer flattening.

We were attempting to override the animated geometry root for all items within the ContainerLayer to prevent component alpha layers from being created.

As part of this we override the opaqueness checks to assume that all layers within the container would contribute since they can't be scrolled by APZ.

When we have async animations however, we use LAYER_ACTIVE_FORCE and still end up with a separate layer that can be animated by the compositor (or by TryUpdateTransformOnly).

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks for the quick turnaround on the fix and the review.  Do we know if this happens just on Linux, or anytime we don't have acceleration?  I would imagine the later, so this is probably a good candidate for an uplift to beta (49)

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Kwierso can you make sure this lands in m-c so we can try and uplift the fix?

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Milan Sreckovic [:milan] from comment #13)
> Do we know if this happens just on Linux, or anytime we don't have acceleration?

Yes -- it happens on Windows as well (I just tested win10, August 20th Nightly, at SoundCloud, with e10s disabled & layers-acceleration force-disabled.  I'm seeing the same issue in that configuration.)

> so this is probably a good candidate for an uplift to beta (49)

Agreed.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f90fc4e6063
Don't assume that layer flattening was 100% successful and treat all layers as opaque. r=tnikkel

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/90a4db6c929d
Don't assume that layer flattening was 100% successful and treat all layers as opaque. r=tnikkel

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/90a4db6c929d

Comment 19

[Gerry Chang [:gchang]]

Track 49+/50+ as this is a visual regression.

Hi :mattwoodrow, 
Since this bug is a regression and also affects 49/50, do you want to uplift this patch to 49/50?

Comment 20

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8783786 [details] [diff] [review]
flattening-bug

Approval Request Comment
[Feature/regressing bug #]: This testcase regressed by bug 1141468, underlying issue is much older.
[User impact if declined]: Rendering issues on songcloud for users without hardware acceleration.
[Describe test coverage new/current, TreeHerder]: Tested manually.
[Risks and why]: Very low risk.
[String/UUID change made/needed]: None

Comment 21

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8783786 [details] [diff] [review]
flattening-bug

Fixes a recent regression, Aurora50+

Comment 22

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Dan, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8783786 [details] [diff] [review]
flattening-bug

Let's uplift to 49 for beta 8 build later this week.

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to Ritu Kothari (:ritu) from comment #22)
> Hi Dan, could you please verify this issue is fixed as expected on a latest
> Nightly build?

Sure! Verified latest nightly, as well as nightlies around comment 18 where this landed.  Using comment 0's STR (along with setting layers.acceleration.disabled=true), I can confirm that Nightly 2016-08-25 shows the bug (graphical artifacts), whereas Nightly 2016-08-26 gives EXPECTED RESULTS (no corruption).

Comment 25

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7968233f352e

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/517b38838e09

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Backed out from Aurora/Beta for causing bug 1299908.

https://hg.mozilla.org/releases/mozilla-aurora/rev/ff1e5019f0c9
https://hg.mozilla.org/releases/mozilla-beta/rev/7579892529ee

Comment 28

[Ryan VanderMeulen [:RyanVM]]

I'll posit that better test coverage would be good here too.

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

Wontfix for 49, as we are now heading into the release candidate build and this caused a release blocking regression. I don't think it's a blocker for release.  We could still potentially take a patch for 50 though.

Comment 30

[Joel Maher ( :jmaher ) (UTC -8)]

verified the backout reverted the performance regressions posted in bug 1299818.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8783786 [details] [diff] [review]
flattening-bug

Matt, did you want to try landing this on Fx50 still or should we wontfix?

Comment 32

[Matt Woodrow (:mattwoodrow)]

Yeah, I think we can, this is a real regression that would be nice to fix.

I've requested approval on bug 1299908.

Comment 33

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8783786 [details] [diff] [review]
flattening-bug

We need to re-land this in Beta50.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/729bb7ca036f

Comment 35

[Ciprian Georgiu, Desktop QA]

I've managed to reproduce this issue on an Nightly build, 51.0a1 from 2016-08-19 with STR from comment 0.

This bug is verified fixed on 50.0b2-build1 (20160926162149) across following OSes:
- Windows 10 x64
- Mac OS 10.11
- Ubuntu 16.04 x64 LTS