1062792 - [Calendar] Week view - Display blank area when scrolling page

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Edward Chen[:edchen]]

[Devices]
Flame

[Environment]
Gaia      a47ecb6368c015dd72148acde26413fd90ba3136
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/757931d0149e
BuildID   20140904000203
Version   34.0a2
ro.build.version.incremental=eng.cltbld.20140820.195518
ro.build.date=Wed Aug 20 19:55:28 EDT 2014


[STR]
1. Launch claendar app
2. Tap week view
3. Scroll up to top
4. Scroll down 
5. Repeat step 3, 4

[Actually result]
1. Display blank area

[Expected result]
1. Normal page view 

[Attachment]
1. Video file: http://youtu.be/kpmDmMl1gGg

Comment 1

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 2

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.2, Flame 2.1, OpenC 2.2

Actual Results: In week view, there is a large black area at the top of the screen.

Repro Rate: 3/3

Environmental Variables:
Device: Flame Master
BuildID: 20140908163110
Gaia: 4acd3e69b263b54f4111e3586ff4ade84b49b4da
Gecko: 6b8da5940f74
Version: 35.0a1 (Master) 
Firmware Version: v123
-----------------------------------------------
Device: Flame 2.1
BuildID: 20140909080656
Gaia: ece265efa8e87765713ac905e8ff55657fcbde01
Gecko: 3b49cf3e2043
Version: 34.0a2 (2.1)
Firmware: V123
------------------------------------------------
Device: Open_C 2.2
BuildID: 20140908062801
Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d
Gecko: f7a27a866c47
Version: 35.0a1 (2.2)
Firmware: P821A10v1.0.0B06_LOG_DL

------------------------------------------------
------------------------------------------------

This bug does NOT repro on: Flame 2.0, Flame 1.4

Actual Result: No problems are seen scrolling in Week view in calendar

Repro Rate: 0/6 attempts

Device: Flame 2.0
BuildID: 20140908131505
Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab
Gecko: de70f9a40834
Version: 32.0 (2.0)
Firmware: V123
------------------------------------------------
Environmental Variables:
Device: Flame 1.4
BuildID: 20140905100238
Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko: a3e8df746cd8
Version: 30.0 (1.4) 
Firmware Version: v123

Comment 3

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: Graphics bug but it looks really bad, plus it is a regression

Comment 4

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140902021513
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: 39a8d9b2b639
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140902025713
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: ea4cfd84e417
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Gaia is the same therefore it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39a8d9b2b639&tochange=ea4cfd84e417

Broken by bug 967844.

Comment 5

[Joshua Mitchell (Inactive)]

Broken by bug 967844 - can you take a look Robert?

Comment 6

[Candice Serran (:cserran)]

unblocking since the platform bug is already marked for feature 2.1. Confirmed this is not a Calendar bug

Comment 7

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

Before I dive into this --- Botond, does this look like any of the bugs you've already been working on?

Comment 8

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

Apparently it doesn't.

Comment 9

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

This is quite likely to be a duplicate of bug 1063046.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Candice Serran (:cserran) from comment #6)
> unblocking since the platform bug is already marked for feature 2.1.
> Confirmed this is not a Calendar bug

Candice - I do not think that has any affect on a blocking decision. A blocking decision is determined by it's impact to the product for a particular release, not to a particular Gaia app. The gecko platform exists as part of the Firefox OS build, which is why it's tracked with the blocking flag. This is a regression from a 2.1 feature and should be triaged against the team that feature applies to.

Comment 11

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

Leaving unassigned until we fix bug 1063046, assuming dependency.

Comment 12

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

Assign, assuming duplicate or at least dependency on bug 1063046, for another test case.

Comment 14

[No-Jun Park [:njpark]]

It looks like even with the fix for bug 1063046, this issue can be seen.

Version info:
Gaia-Rev        37b8a812c642ca616bf9457cb9b71e45261cdfa8
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/9e193395b912
Build-ID        20140923065343
Version         35.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20140923.101842
FW-Date         Tue Sep 23 10:18:53 EDT 2014
Bootloader      L1TC10011800

Comment 15

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

Actually, this looks more like either z-order or something with the fixed header on top, because the black is exactly lined up with the element that is being scrolled.  Are we sure the calendar CSS is correct?

Comment 16

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

As far as I can tell the calendar CSS looks fine. Layout is truncating the visible region of one of the PaintedLayers and so it ends up showing garbage (black most of the time) in that area instead.

Comment 17

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

Attachment: Content-side display list dump

The layer at 0xb3e98210 has a truncated visible rect - the height is only 77 pixels when it should be 180 pixels (which is what it is when you scroll the calendar view up to the top).

Comment 18

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

tn, can you take it from here? Let me know if you can't reproduce or anything else is blocking you on this. I'd give it to roc but he's away for the next week and a half.

Comment 19

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

Also, it'd be good to know why this doesn't reproduce with the day view, which (to the user) looks to have the same behaviour...

Comment 20

[Miller Medeiros [:millermedeiros]]

Day View still have a different structure (we will update it soon to match week view). Day view doesn't scroll sideways and we also don't toggle the overflow-y or the main area based on the touch events.

Same code was working fine with Gecko from the end of July. I don't know when the problem started to happen. I know that behavior changed a little bit the past few weeks.

Comment 22

[Timothy Nikkel (:tnikkel)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #17)
> Created attachment 8498349 [details]
> Content-side display list dump
> 
> The layer at 0xb3e98210 has a truncated visible rect - the height is only 77
> pixels when it should be 180 pixels (which is what it is when you scroll the
> calendar view up to the top).

The layer containing the fixed pos content (which is 0xb3e98210) is below the layer containing the scrolled content, which is clearly a problem since the scrolling content it supposed to scroll under the fixed pos content.

Comment 23

[Timothy Nikkel (:tnikkel)]

(In reply to Timothy Nikkel (:tn) from comment #22)
> The layer containing the fixed pos content (which is 0xb3e98210) is below
> the layer containing the scrolled content, which is clearly a problem since
> the scrolling content it supposed to scroll under the fixed pos content.

Nevermind, there is no fixed pos content, the scrolling in in a scrollable div, not the root scroll frame. Patch for the real problem coming up.

Comment 24

[Timothy Nikkel (:tnikkel)]

Attachment: clip region before adding to opaque region

We need to apply the layer's clip rect to the layer's opaque region before adding it to the opaque region.

Comment 25

[Timothy Nikkel (:tnikkel)]

Bug 1022612 added this code, it's just that bug 967844 exposed this problem, so adding dependency.

Comment 26

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

Comment on attachment 8505794 [details] [diff] [review]
clip region before adding to opaque region

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

Test?

Comment 27

[Tony Chung [:tchung]]

Any update on this blocker?  this is still reproducible on 2.1 and a terrible user experience.

Comment 28

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

Right, there is an r+ patch.

Comment 29

[Timothy Nikkel (:tnikkel)]

I've been battling to create a test for this bug. I think I finally have one.
pending try job:
https://tbpl.mozilla.org/?tree=Try&rev=02186e067ca3

Comment 30

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5d7e28f80b98

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5d7e28f80b98

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Please request b2g34 approval on this patch when you get a chance :)

Comment 33

[Timothy Nikkel (:tnikkel)]

Attachment: clip region before adding to opaque region (with test)

Comment 34

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8510024 [details] [diff] [review]
clip region before adding to opaque region (with test)

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 #): bug 967844
User impact if declined: some parts of pages don't get drawn when they should
Testing completed: locally tested, and on mozilla-central
Risk to taking this patch (and alternatives if risky): pretty low risk
String or UUID changes made by this patch: none

Comment 35

[No-Jun Park [:njpark]]

fix looks good in master branch

Comment 36

[Tony Chung [:tchung]]

(In reply to Timothy Nikkel (:tn) from comment #34)
> Comment on attachment 8510024 [details] [diff] [review]
> clip region before adding to opaque region (with test)
> 
> 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 #): bug 967844
> User impact if declined: some parts of pages don't get drawn when they should
> Testing completed: locally tested, and on mozilla-central
> Risk to taking this patch (and alternatives if risky): pretty low risk
> String or UUID changes made by this patch: none

ni? bhavana to get this +'d for 2.1 uplift.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/1e6acd69898a

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Backed out for linux32 debug (and only that) m-oth orange:
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4f8c0c021128

https://treeherder.mozilla.org/ui/logviewer.html#?job_id=14247&repo=mozilla-b2g34_v2_1

Comment 39

[Timothy Nikkel (:tnikkel)]

The test checks that there is no overlap (or underlap) in the layers that make up a default empty (desktop) Firefox browser window. It would be interesting to know what changeset causes us not to see this problem on mozilla-central.

Comment 40

[Timothy Nikkel (:tnikkel)]

On the mozilla-b2g34_v2_1 repo the changesets from bug 1062100 are what make landing this orange. These changesets are of course on mozilla-central, so there must be another set of changes that fix this problem.

Comment 41

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

Probably bug 1066591?

Comment 42

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

Oh no, never mind. The uplifts from bug 1062100 had the corrected versions of the patches, which included the backout from 1066591 and relanding.

Comment 43

[Timothy Nikkel (:tnikkel)]

Doing a bunch more try pushes to track this down.

Comment 45

[Timothy Nikkel (:tnikkel)]

Looks like bug 1068961 fixes this failure on mozilla-central:

The first good revision is:
changeset:   207551:62e308af0e0d
user:        Botond Ballo <[e-mail]>
date:        Fri Sep 26 14:11:17 2014 -0400
summary:     Bug 1068961 - Reset clip rect for color layers. r=roc

I'm going to suggest that we uplift that too.

Comment 46

[Edward Chen[:edchen]]

[Environment]
Gaia-Rev        0dfc1996eb583c8b507a82bf6b8319624bba23ea
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/80e18ff7c7b2
Build-ID        20141029160202
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880


[Result]
PASS

Comment 47

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/1e114ba71a0e

Comment 49

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.1.

Result: No black area is observed during scrolling.

Device: Flame 2.1 (319mb, KK, Shallow Flash)
BuildID: 20141111001201
Gaia: 7154f9aa0a69af56c8bd89be0c98d9791449527b
Gecko: 452db1a0c9a0
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

=======================================================
However, there is a new issue found on Flame 2.2 during scrolling. Filed a new bug 1097144

Comment 50

[Yeojin Chung [:YeojinC]]

> However, there is a new issue found on Flame 2.2 during scrolling. Filed a
> new bug 1097144

Correction: The new bug seems to be a separate issue. Verified fixed on 2.2 since the original issue is resolved. 

Device: Flame 2.2 (319mb, KK, Shallow Flash)
BuildID: 20141111040202
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: 76b85b90a8cb
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0