1099445 - [Calendar] Stretching the page on the Edit Event page causes a black box to appear

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Robert Mead [:RobertM]]

Attachment: Flame2.1logcat.txt

Description:
While in Calendar, if you select an event and choose to edit it, scrolling to cause the page to stretch causes a black box to appear.

Prereq:
Have an event created in the calendar app

Repro Steps:
1) Update a Flame device to BuildID: 20141114001204
2) Tap 'Calendar' app
3) Go to week view
4) Tap the event
5) Tap the 'Edit' button
6) Try to scroll  up to stretch the screen and observe

Actual:
The screen stretches and creates a black box

Expected: 
The screen stretches but does not create a black box


Flame 2.1(319mb)(KitKat)(Shallow Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141114001204
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 551326425826
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency: 100%
See attached: logcat, video - http://youtu.be/nmah4XOVEdU

Comment 1

[Robert Mead [:RobertM]]

This issue does NOT occur in Flame 2.0(319mb) and Flame 2.2(319mb)

While on the Edit Event page in calendar, stretching the screen does not cause a black box to occur

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141114000200
Gaia: 28991b28d54fc4ef8112c8fa678bf20f9faca8c8
Gecko: 62294be0fc98
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141114040205
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: bbb68df450c2
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This seems like it could be a dupe of bug 1093298. Waiting till patch lands to check before triaging this bug.

Comment 3

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

[Blocking Requested - why for this release]:

This bug seems to be occurring still. Nominating to block 2.1. This black bar appearing from scrolling on the new event page covers up info and Causes a poor UX

Comment 4

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

Bug 1092842 seems to be the cause for this issue.

B2g-34 Regression Window:

Last Working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20141113112008
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 252a33e86472
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20141113180633
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 551326425826
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 551326425826

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 252a33e86472

Gecko Pushlog: http://hg.mozilla.org/releases/mozilla-b2g34_v2_1/pushloghtml?fromchange=252a33e86472&tochange=551326425826

Comment 5

[Joshua Mitchell (Inactive)]

Broken by Bug 1092842

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sorry about the delay. I'm working on this.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Botond, this is an overscroll-related bug --- see http://youtu.be/nmah4XOVEdU. *something* doesn't get adjusted by the overscroll transform during compositing and causes black regions to appear. Does this look like a bug that was fixed on trunk?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: paint and layer tree dumps when the bug is present

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: paint and layer tree dumps when the bug is absent

I think the important difference between this dump and the previous one is that when the bug is present, some of the Client layers have complex visible/valid regions. When the bug is absent, the corresponding Client layers have only a single rectangle for their visible/valid regions.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Derek Harris [:DerekH] from comment #2)
> This seems like it could be a dupe of bug 1093298. Waiting till patch lands
> to check before triaging this bug.

It looks to me like 1093298 has not been backported to 2.1!

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Unfortunately porting the fix for bug 1093298 to 2.1 did not fix this bug.

Comment 12

[Botond Ballo [:botond]]

Bug 1093298 fixes a regression caused by bug 1066888, which only landed for 2.2, so it makes sense that this is a different issue. 

Leaving ni until I can investigate tomorrow.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, it's not actually overscroll-related. You can see the black background of the "Notes" field lagging behind async scrolling even before overscroll is triggered.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9)
> I think the important difference between this dump and the previous one is
> that when the bug is present, some of the Client layers have complex
> visible/valid regions. When the bug is absent, the corresponding Client
> layers have only a single rectangle for their visible/valid regions.

That's completely wrong.

The difference is in the first scrolled ClientThebesLayer. In the "bad" layer tree, it's marked opaqueContent, and in the "good" layer tree, it's not marked opaque. This layer contains the background and borders of the "Notes" text input, which (when you interact with the app) is clearly related to the problem, since the errant black area tracks the Notes text input (but is covered by it). Everything else in the layer dump for these layers is the same.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 1092842 affects the opaqueContent status of the layer because before that bug is fixed, the background-color for each of the three text inputs is clipped to the inside of the borders. Our opacity analysis is then unable to determine that the background-color plus the solid border of each of the three text inputs are all opaque and together cover visible region of the layer. After fixing bug 1092842, the background colors are not clipped to the inside of the borders, so analysis concludes that the background colors of the text inputs are opaque and together cover the visible region of the layer.

That makes me very confident that this bug could be reproduced without the fix for bug 1092842, e.g. if you replaced the text inputs with an equivalent element without borders.

Comment 16

[Botond Ballo [:botond]]

Based on comments 13-15, this sounds like a general issue with async scrolling which can been exposed / hidden by various changes to the page / layer structure. Categorizing as APZ for now.

It might be useful to know what fixed it in 2.2, although it might end up just being another change to the page or layer structure which hid the problem.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I attached LayerScope (great tool!). It shows that the layer contents seem to be correct. Our suspect layer:
[visible=< (x=23, y=15, w=435, h=60); (x=23, y=90, w=435, h=60); (x=23, y=624, w=435, h=150); >] [opaqueContent]
looks a bit weird in LayerScope because it's marked as opaque, but most of it is invalid and the invalid parts of the tiles contain leftovers from other layers.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If I disable culling in the compositor (by making GetOpaqueRect always return an empty rect), the problem goes away.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The bug is because the compositor culling logic currently in b2g34 is broken. GetOpaqueRect and ContainerPrepare in ContainerLayerComposite call GetBaseTransform, which doesn't account for async transforms, so we cull as if async-scrolled layers aren't async-scrolled. In this particular testcase, that means we clip out the area of the opaque "Notes" field when painting the main background layer (because the "Notes" field is the largest rectangle in its layer's visible region).

This would have been fixed on trunk by bug 1085223, Matt's rewrite of the culling logic.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8529718 [details] [diff] [review]
fix

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): the underlying bug is very old but the patch in bug 1092842 exposed it in the Calendar app
User impact if declined: bad rendering in Calendar app and likely elsewhere
Testing completed: minimal, but the patch here resembles what's in 2.2
Risk to taking this patch (and alternatives if risky): pretty low risk; small well-understood change
String or UUID changes made by this patch: none

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9faa165ac85d

Comment 23

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

This bug is fixed on 2.1, where it was reported. It doesn't happen on 2.2, so I'm marking this bug resolved as there's nothing left to do here. Please correct me if I'm mistaken.

Comment 24

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.1.

Result: No black area appears while scrolling the page.

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141219001200
Gaia: 6af3d029bae3a14f400fec0926f0f8ad7b579b4b
Gecko: d41f6bd64343
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0