1132741 - [Window Mgmt] Pulling down notification tray is missing transparent background layer

Status: RESOLVED DUPLICATE of bug 1137203

(Core :: Graphics: Layers, defect)

Description

[Brogan Zumwalt [Inactive]]

Description:
When user pulls down notification tray, the transparent grey background layer of the tray is missing. Only when tray is fully extended is the layer visible. This issue occurs when user flicks down tray, issue does not appear when pulling down manually at a steady rate.

Repro Steps:
1) Update a Flame to 20150212064620
2) Flick down at top of screen to expand notification tray.

Actual:
Grey background layer is missing during tray pull down animation.

Expected:
Grey background layer is visible at all times during tray pull down animation.

Environmental Variables:
Device: Flame 3.0 Master
Build ID: 20150212064620
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 81f979b17fbd
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 3/3, 100%
See attached: Youtube video clip: http://youtu.be/aX3kILNZGHw

Comment 1

[Brogan Zumwalt [Inactive]]

Issue does NOT occur on latest Flame 2.2

Grey background layer is visible at all times during tray pull down animation.

Device: Flame 2.2
Build ID: 20150212133255
Gaia: ab9029f2b203e2a36e8f81edd17fa5ff81c874b5
Gecko: b1d3839680fb
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

This is a regression and looks bad so nominating 3.0?

Comment 3

[Shally Li（leave from Mozilla）]

I'm finding the broken window.

Comment 4

[Shally Li（leave from Mozilla）]

inbound Regression Window:

Last Working build: 
Gaia-Rev        d5a71cedb37dd45f439f672489db3994b349ac43
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/3094601af679
Build-ID        20150212010213
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150212.042740
FW-Date         Thu Feb 12 04:27:51 EST 2015
Bootloader      L1TC000118D0

First Broken build:
Gaia-Rev        2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/81f979b17fbd
Build-ID        20150212064620
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150212.042740
FW-Date         Thu Feb 12 04:27:51 EST 2015
Bootloader      L1TC000118D0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia Revision          d5a71cedb37dd45f439f672489db3994b349ac43
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/81f979b17fbd

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia Revision          2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3094601af679


Gecko Video&Log:video_v3.0.mp4 and (Last Working gaia_First Broken gecko)logcat_0032.txt.

Comment 5

[Shally Li（leave from Mozilla）]

Attachment: (Last Working gaia_First Broken gecko)logcat_0032.txt

Comment 6

[Shally Li（leave from Mozilla）]

Attachment: video_v3.0.mp4

Comment 7

[Johan Lorenzo [:jlorenzo]]

Per regression window in comment 4. FWIW, I can see this kind of flickering when the callscreen goes down while receiving a call.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

The window in comment 4 appears to be a mozilla-central window. Can we narrow it down to an inbound window?

Comment 10

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1127066 seems to be the cause for this issue.  

Mozilla-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150211190942
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 6ed69c4d2c15
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First Broken 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150211230942
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 07479758ab68
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 07479758ab68

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 6ed69c4d2c15

Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6ed69c4d2c15&tochange=07479758ab68

I had been working on this window last night (which is why I was the qa contact on this bug) but was just unable to finish it.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Ok, thanks. I'll take a look at it then.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

I bisected further and the regression is coming from part 6, presumably setting the displayport is causing this to happen.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

I got display list and layer dumps with and without part 6, and the primary difference between the two is that in the buggy version the valid region on a PaintedLayer is smaller than in the non-buggy version. The PaintedLayer is also tiled in the buggy version but not otherwise. This indicates a problem in the tiling code, because that fiddles with the valid region a bunch. I also turned off tiling by setting layers.enable-tiles to false and that made the problem go away. So it's almost certainly a tiling problem.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Attachment: Always fully draw tiled layers subject to async transforms

Needs more testing and a try push, but does this feel reasonable to you?

Comment 15

[Kartikaya Gupta (email:[e-mail])]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6e7c0bf136ef

Comment 16

[:gerard-majax]

Kats, I've applied your patch on my Aries tree, and it seems to fix the reported issue, but it creates new issues:
 - twitter content not showing up, only menu buttons are visibles,
 - rocketbar partly disappeared after I scrolled and used the notification tray,

Comment 17

[:gerard-majax]

Attachment: Rocketbar issue

Comment 18

[:gerard-majax]

Attachment: Twitter issue

Comment 19

[Kartikaya Gupta (email:[e-mail])]

I don't see either of these issues on the flame. The twitter app from the marketplace renders fine and i tried different combinations of scrolling and using the notification tray on the homescreen and the rocketbar always paints fine.

I recall you were trying different tile sizes or something recently, do you have any local changes that might be causing this (maybe in combination with my patch?)

Comment 20

[:gerard-majax]

Not on this one.

Comment 21

[:gerard-majax]

When I reproduce the issue (it takes a couple of minutes before kicking in with the pending patch applied), I have noticed that content is properly displayed in the task manager: I see the webpage. If I switch back to the page, I still see nothing. I do see stuff, however, during the edge gestures transitions.

Comment 22

[Kan-Ru Chen [:kanru] (UTC+9)]

Attachment: Here Login issue

Here Login also appears as blank until I touch the invisible input field with today's nightly build (which is without the patch here I think)

Comment 23

[Kan-Ru Chen [:kanru] (UTC+9)]

Attachment: Rocketbar issue 2

I also observe rocketbar issue today

Comment 24

[Kartikaya Gupta (email:[e-mail])]

Thanks, Kan-Ru! Looks like the issues are not caused by my patch then. Could either of you file a new bug for that?

Comment 25

[Johan Lorenzo [:jlorenzo]]

@Kan-Ru, it looks like bug 1133518.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

Bug 1127066 has been uplifted to 2.2, so this bug will start manifesting there as well.

Comment 27

[Benoit Girard (:BenWa)]

Comment on attachment 8564374 [details] [diff] [review]
Always fully draw tiled layers subject to async transforms

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

We discussed this on IRC. We decided that we don't have a good reason to have rasterization decision differ for an OMTA layer. It would also mean that we could have hard to find bugs with OMTA layers so I'd rather just do this for all layers that take UseFastPath. Taking r? off since I didn't review the patch in depth.

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch v2

Updated patch as per IRC discussion, verified that it fixes the problem. Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fe025d93038f

Note also that the code was added in bug 1121871 and honestly the patch there doesn't make much sense to me at all.

Comment 31

[Kartikaya Gupta (email:[e-mail])]

After further discussion with BenWa we decided to just back out the patch in bug 1121871 and investigate that more to find a more comprehensive solution. I verified that backing out that patch fixes this bug as well as bug 1132980 and bug 1133105.

Comment 32

[Kartikaya Gupta (email:[e-mail])]

Backed out bug 1121871: https://hg.mozilla.org/integration/b2g-inbound/rev/333cd39619fe

Leaving this open until that backout gets merged to m-c.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/333cd39619fe

Comment 34

[Kartikaya Gupta (email:[e-mail])]

Thanks. This particular bug shouldn't be on 2.1 because it also requires APZ enabled in the parent-process which is only 2.2+.

Comment 35

[Chris Lord [:cwiiis]]

I still see this bug with the back-out... Applying attachment #8564374 [details] [diff] [review] fixes it.

I won't reopen in case I've made a mistake, but could you verify this kats? The usual STR are enough to expose it for me (open the tray with a quick, short movement).

Comment 36

[Kartikaya Gupta (email:[e-mail])]

Well the back-out was backed-out, so this needs reopening regardless. I'm not sure if you picked up the backout of the backout too, that might explain it.

Comment 37

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #36)
> Well the back-out was backed-out, so this needs reopening regardless. I'm
> not sure if you picked up the backout of the backout too, that might explain
> it.

ah, I missed that the back out was backed out, I probably had that applied too.

Comment 39

[Stephany Wilkes]

Triage is blocking because this is a regression.

Comment 42

[Gregor Wagner [:gwagner]]

What's the status here?

Comment 43

[Kartikaya Gupta (email:[e-mail])]

The patch on bug 1134762 fixes this but we need to sort out a crashtest failure before we can land it. We are working on it actively (although mostly waiting for try runs).

Comment 45

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #43)
> The patch on bug 1134762 fixes this but we need to sort out a crashtest
> failure before we can land it. We are working on it actively (although
> mostly waiting for try runs).

I'm still seeing this issue running a Gecko build with said patch landed.

Comment 46

[:gerard-majax]

(In reply to Chris Lord [:cwiiis] from comment #45)
> (In reply to Kartikaya Gupta (email:[e-mail]) from comment #43)
> > The patch on bug 1134762 fixes this but we need to sort out a crashtest
> > failure before we can land it. We are working on it actively (although
> > mostly waiting for try runs).
> 
> I'm still seeing this issue running a Gecko build with said patch landed.

Smae for me.

Comment 47

[Kartikaya Gupta (email:[e-mail])]

Yeah, I'm seeing it too. I think we need to make the tiling code OMTA-aware after all, filed bug 1137203 for it.