Closed Bug 1132741 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1137203
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: bzumwalt, Assigned: kats)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing])

Attachments

(7 files, 1 obsolete file)

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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
QA Contact: jmercado
[Blocking Requested - why for this release]:

This is a regression and looks bad so nominating 3.0?
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I'm finding the broken window.
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.
Per regression window in comment 4. FWIW, I can see this kind of flickering when the callscreen goes down while receiving a call.
Component: Gaia::System::Window Mgmt → Panning and Zooming
Product: Firefox OS → Core
The window in comment 4 appears to be a mozilla-central window. Can we narrow it down to an inbound window?
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.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Ok, thanks. I'll take a look at it then.
Assignee: nobody → bugmail.mozilla
Blocks: 1127066
I bisected further and the regression is coming from part 6, presumably setting the displayport is causing this to happen.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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.
Needs more testing and a try push, but does this feel reasonable to you?
Attachment #8564374 - Flags: feedback?(bgirard)
Attachment #8564374 - Flags: feedback?(bgirard) → review?(bgirard)
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,
Flags: needinfo?(bugmail.mozilla)
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?)
Flags: needinfo?(bugmail.mozilla) → needinfo?(lissyx+mozillians)
Not on this one.
Flags: needinfo?(lissyx+mozillians)
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.
Flags: needinfo?(bugmail.mozilla)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Attached image 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)
Attached image Rocketbar issue 2
I also observe rocketbar issue today
Thanks, Kan-Ru! Looks like the issues are not caused by my patch then. Could either of you file a new bug for that?
Flags: needinfo?(bugmail.mozilla)
@Kan-Ru, it looks like bug 1133518.
Bug 1127066 has been uplifted to 2.2, so this bug will start manifesting there as well.
blocking-b2g: 3.0? → 2.2?
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.
Attachment #8564374 - Flags: review?(bgirard)
Attached patch Patch v2Splinter Review
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.
Attachment #8564374 - Attachment is obsolete: true
Attachment #8565568 - Flags: review?(bgirard)
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.
Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/333cd39619fe
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
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+.
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).
Flags: needinfo?(bugmail.mozilla)
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.
Status: RESOLVED → REOPENED
Flags: needinfo?(bugmail.mozilla)
Resolution: FIXED → ---
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Blocks: 1134202
Component: Panning and Zooming → Graphics: Layers
Target Milestone: mozilla38 → ---
Duplicate of this bug: 1132856
Triage is blocking because this is a regression.
blocking-b2g: 2.2? → 2.2+
Duplicate of this bug: 1135452
Duplicate of this bug: 1135732
What's the status here?
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).
Duplicate of this bug: 1136530
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
(In reply to Chris Lord [:cwiiis] from comment #45)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Yeah, I'm seeing it too. I think we need to make the tiling code OMTA-aware after all, filed bug 1137203 for it.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1137203
You need to log in before you can comment on or make changes to this bug.