Closed Bug 1062792 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla36
Project Flags:
blocking-b2g 2.1+
Tracking Flags:
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: edchen, Assigned: tnikkel)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Content-side display list dump
60.49 KB, text/plain
Details
clip region before adding to opaque region (with test)
4.14 KB, patch
bajaj
: approval-mozilla-b2g34+
Details | Diff | Splinter Review 
[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
QA Wanted for branch checks.
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
[Blocking Requested - why for this release]: Graphics bug but it looks really bad, plus it is a regression
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: edchen
QA Contact: pcheng
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Broken by bug 967844 - can you take a look Robert?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(roc)
unblocking since the platform bug is already marked for feature 2.1. Confirmed this is not a Calendar bug
blocking-b2g: 2.1? → ---
Before I dive into this --- Botond, does this look like any of the bugs you've already been working on?
Flags: needinfo?(roc) → needinfo?(botond)
Apparently it doesn't.
Flags: needinfo?(botond)
This is quite likely to be a duplicate of bug 1063046.
Depends on: 1063046
(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.
blocking-b2g: --- → 2.1?
Component: Gaia::Calendar → Graphics
Product: Firefox OS → Core
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Leaving unassigned until we fix bug 1063046, assuming dependency.
blocking-b2g: 2.1? → 2.1+
Assign, assuming duplicate or at least dependency on bug 1063046, for another test case.
Assignee: nobody → bgirard
See Also: → 1071574
See Also: → 1071718
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
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?
Assignee: bgirard → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
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.
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
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).
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.
Assignee: bugmail.mozilla → tnikkel
Component: Graphics → Layout
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...
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.
Blocks: 1081904
No longer blocks: 1081904
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
(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.
We need to apply the layer's clip rect to the layer's opaque region before adding it to the opaque region.
Attachment #8505794 - Flags: review?(roc)
Bug 1022612 added this code, it's just that bug 967844 exposed this problem, so adding dependency.
Blocks: 1022612
Comment on attachment 8505794 [details] [diff] [review]
clip region before adding to opaque region

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

Test?
Attachment #8505794 - Flags: review?(roc) → review+
No longer blocks: 1079383
See Also: → 1079383
Any update on this blocker?  this is still reproducible on 2.1 and a terrible user experience.
Right, there is an r+ patch.
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
https://hg.mozilla.org/mozilla-central/rev/5d7e28f80b98
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Please request b2g34 approval on this patch when you get a chance :)
status-b2g-v2.2: affected → fixed
status-firefox34: --- → wontfix
status-firefox35: --- → wontfix
status-firefox36: --- → fixed
Flags: needinfo?(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
Flags: needinfo?(tnikkel)
Attachment #8510024 - Flags: approval-mozilla-b2g34?
fix looks good in master branch
(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.
Flags: needinfo?(bbajaj)
Flags: needinfo?(bbajaj)
Attachment #8510024 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
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.
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.
Oh no, never mind. The uplifts from bug 1062100 had the corrected versions of the patches, which included the backout from 1066591 and relanding.
Doing a bunch more try pushes to track this down.
Looks like bug 1068961 fixes this failure on mozilla-central:

The first good revision is:
changeset:   207551:62e308af0e0d
user:        Botond Ballo <botond@mozilla.com>
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.
[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
Status: RESOLVED → VERIFIED
Depends on: 1097144
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
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+][failed-verification]
status-b2g-v2.1: fixed → verified
Flags: needinfo?(ktucker)
> 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
QA Whiteboard: [QAnalyst-Triage?][lead-review+][failed-verification] → [QAnalyst-Triage?][lead-review+]
status-b2g-v2.2: fixed → verified
No longer depends on: 1097144
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
See Also: → 1099001
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: