1070993 - Entering or scrolling in call log sometimes shows empty list

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Gregor Wagner [:gwagner]]

In 2.1: Entering edit mode or scrolling of call-log entries sometimes results in an empty list.

Comment 1

[Gregor Wagner [:gwagner]]

[Blocking Requested - why for this release]:

Comment 2

[Johan Lorenzo [:jlorenzo]]

QA Wanted for a video and more detailed STR if possible.

Comment 3

[Joshua Mitchell (Inactive)]

Dupe of bug 1061616?

Comment 4

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: this should block because it's data loss.

Comment 5

[Johan Lorenzo [:jlorenzo]]

I was able to repro 5/5 times the issue by triggering the bottom end overscroll and immediately (without letting it finish) the top end overscroll. See video for more details: http://mzl.la/1wIWidd

Comment 6

[Anthony Ricaud (:rik)]

This is not bug 1061616 and this is not a data loss. It's a graphic glitch. Bad enough to be 2.1 blocker though.

Comment 7

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

Please see this video: http://youtu.be/FftBeppCHZM

Steps to Reproduce:
1) Update a Flame to 20140922185144
2) Make sure at least 8 calls are in the call log. (Use reference workloads if possible)
3) Open the Call log and press the edit mode button.
4) Scroll the list

Actual:
A blank list is viewed as edit mode is opened or is viewed while scrolling edit mode.  Scrolling more will cause the list to become visible or not again.

Expected:
The call list is always viewable.



This issue does occur on 2.1 KK Flame.

Environmental Variables:
Device: Flame 2.1
BuildID: 20140922185144
Gaia: 3742913e11f69e789dcb0aa0dedf2e5572da0129
Gecko: df42b05782aa
Version: 34.0a2 (2.1) 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

This issue does NOT occur on 2.2 KK Flame, 2.0 KK Flame, and the v180 KK Flame base.

Environmental Variables:
Device: Flame 2.2
BuildID: 20140923065343
Gaia: 37b8a812c642ca616bf9457cb9b71e45261cdfa8
Gecko: 9e193395b912
Version: 35.0a1 (2.2) 
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140923071344
Gaia: 6449cc35a8f0704d95acac374ba857bde4b86d6c
Gecko: f18695cae418
Version: 32.0 (2.0) 
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 8

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

Bug 1013385 seems to be the cause for this issue.

Aurora Regression Window:

Last working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140919134559
Gaia: 8923fc6755756b14b66d13c45678b53fcac6e8c5
Gecko: 8b58f3f4f05a
Version: 34.0a2 (2.1) 
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140919143448
Gaia: 58676ebbf1d3467463ced09a8c0a1e461c3a6d8e
Gecko: 6d8a53b071f7
Version: 34.0a2 (2.1) 
Firmware Version: 
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: 8923fc6755756b14b66d13c45678b53fcac6e8c5
Gecko: 6d8a53b071f7

First broken gaia / Last working gekko - Issue does NOT occur
Gaia: 58676ebbf1d3467463ced09a8c0a1e461c3a6d8e
Gecko: 8b58f3f4f05a

Gecko Pushlog: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=8b58f3f4f05a&tochange=6d8a53b071f7

Comment 9

[Joshua Mitchell (Inactive)]

Broken by Bug 1013385 ?

Comment 10

[Anthony Ricaud (:rik)]

Kats: Could you take a look at this?

Comment 11

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

I'm at a workweek and don't have a Flame to flash with 2.1 at the moment. I'll look at this next week. In the meantime if this is blocking people feel free to back bug 1013385 out of aurora. Most likely we missed uplifting something to 2.1 but I'll have to investigate.

Comment 12

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

I was able to reproduce this. The problem is easily reproducible if you do a horizontal scroll on the edit-call-log screen. There is some rounding error that gets introduced, so we end up with scroll offsets of 0.0002 on some of the container layers and APZC::IsCurrentlyCheckerboarding continuously returns true. Bug 1066259 fixes this rounding error on 2.2, and when I apply the aurora-rebased patch for that bug, I don't see this on 2.1 either. When that patch lands on aurora it should fix this.

However, there's some additional robustification I can do here so I'll put up a patch for that as well.

Comment 13

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

Attachment: Fuzz the checkerboarding check by 1 app unit

This is the same fuzz that I used before at http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/TiledContentClient.cpp?rev=0e9250899401#264 and it worked well enough there.

Comment 14

[Botond Ballo [:botond]]

Comment on attachment 8496800 [details] [diff] [review]
Fuzz the checkerboarding check by 1 app unit

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

The fuzzing looks reasonable.

However, why does a wrong return value from IsCurrentlyCheckerboarding() cause such a bad rendering problem to begin with? My understanding based on a quick reading of how this function is used is that if it returns true, we draw a background before drawing the layer contents to avoid the checkerboarded region showing garbage, but then we still draw the layer contents on top.

Comment 15

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

(In reply to Botond Ballo [:botond] from comment #14)
> However, why does a wrong return value from IsCurrentlyCheckerboarding()
> cause such a bad rendering problem to begin with? My understanding based on
> a quick reading of how this function is used is that if it returns true, we
> draw a background before drawing the layer contents to avoid the
> checkerboarded region showing garbage, but then we still draw the layer
> contents on top.

Yeah, it's kind of a bad layer tree where the layer has a large transparent region in the middle. In the dump at [1] the very last thebes layer gets flagged as having a checkerboarding APZC, because it's parent container layer has the rounding error in its scroll offset. So that last thebes layer draws a full white background, and then on top of it draws its content. It's content happens to be the header at the top of the page and the footer at the bottom of the page, and a large transparent region in between through which you're supposed to be able to see the "real" content. But now that transparent region has a background and so that's what ends up being visible.

[1] https://bug1047080.bugzilla.mozilla.org/attachment.cgi?id=8496952

Comment 16

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

https://hg.mozilla.org/integration/b2g-inbound/rev/df363eb7ac1a

Comment 17

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #15)
> Yeah, it's kind of a bad layer tree where the layer has a large transparent
> region in the middle. In the dump at [1] the very last thebes layer gets
> flagged as having a checkerboarding APZC, because it's parent container
> layer has the rounding error in its scroll offset. So that last thebes layer
> draws a full white background, and then on top of it draws its content. It's
> content happens to be the header at the top of the page and the footer at
> the bottom of the page, and a large transparent region in between through
> which you're supposed to be able to see the "real" content. But now that
> transparent region has a background and so that's what ends up being visible.

That makes sense - thanks!

Will it eventually be possible to improve the background-drawing code to only draw a background under opaque regions?

Comment 18

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

That would be nice, but I can't think of any easy way to accomplish that without exposing more stuff in the layers API.

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/df363eb7ac1a

Comment 23

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

Comment on attachment 8496800 [details] [diff] [review]
Fuzz the checkerboarding check by 1 app unit

Approval Request Comment
[Feature/regressing bug #]: bug 1013385
[User impact if declined]: in various conditions we end up showing blank white transiently or permanently in places we shouldn't. see the various bugs that have been duped to this one
[Describe test coverage new/current, TBPL]: none, local manual testing only
[Risks and why]: low-risk. the underlying problem is just some small rounding error which I've run into before and should have anticipated. The fix is pretty small. Affects all platforms with APZ enabled (i.e. B2G/Metro)
[String/UUID change made/needed]: none

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/066617542782

Comment 26

[Rachel Pribble [:rpribble]]

VERIFIED FIXED on v2.2 and v2.1.

Environmental Variables:

Device: Flame 2.1 KK (319 MB)
BuildID: 20141011000201 (full flash)
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: d813d79d3eae
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master KK (319 MB)
BuildID: 20141012040203 (full flash)
Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab
Gecko: 44168a7af20d
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Contact list scrolls without disappearing.