964997 - homescreen is rendered incorrectly when try to scroll more with APZC is enabled

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Sotaro Ikeda [:sotaro]]

By the following STR, sometime homescreen is incorrectly rendered. It seems like try to scroll more right, even when the pane is right most pane.

STR
[1] In the homescreen, move to right most pane.
[2] In the right most pane, try to scroll more right. Touch the screen very quickly.

I confirmed the problem happened by recent master hamachi and v1.3 hamachi.
nexus-4 also happen the problem. But it was very hard to reproduce it.

Comment 1

[Sotaro Ikeda [:sotaro]]

Attachment: The movie the problem happned

Comment 2

[Sotaro Ikeda [:sotaro]]

The problem does not happen when APZC is disabled.

Comment 4

[Preeti Raghunath(:Preeti)]

Please review for APZC

Comment 5

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

Preeti, even with "it is really hard to reproduce", we're considering this a 1.3 blocker?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Milan Sreckovic [:milan] from comment #5)
> Preeti, even with "it is really hard to reproduce", we're considering this a
> 1.3 blocker?

Homescreen has a high quality bar for ship & can potentially can cause a part of the UI to be non-functional if the glitch persists (see the dupe). That was why we blocked on it.

Comment 7

[Sotaro Ikeda [:sotaro]]

> 
> I confirmed the problem happened by recent master hamachi and v1.3 hamachi.
> nexus-4 also happen the problem. But it was very hard to reproduce it.

It was hard to reproduce only on nexus-4. On hamachi, it was easily reproducible.

Comment 8

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

Let's find the regression window and then take a look at what caused this.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Milan Sreckovic [:milan] from comment #8)
> Let's find the regression window and then take a look at what caused this.

We already confirmed this - it was caused by enabling of APZC. comment 2 indicates this doesn't reproduce with APZC disabled.

Comment 10

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

(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Milan Sreckovic [:milan] from comment #8)
> > Let's find the regression window and then take a look at what caused this.
> 
> We already confirmed this - it was caused by enabling of APZC. comment 2
> indicates this doesn't reproduce with APZC disabled.

I didn't want to make the assumption that comment meant "this never worked with APZC on", and wanted to explore the "this stopped working with APZC on" possibility.  But if we know this never worked with APZC on, or at least have a good reason to believe it to be so, you're right, we don't need the regression range.

Comment 11

[Jason Smith [:jsmith]]

Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce with APZC disabled?

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce
> with APZC disabled?

I confirmed it with botond. I will confirm it again.

Comment 13

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

I can reproduce this, but I'm unsure that bug 965077 is a duplicate of this. Based on the video there I think this bug might be showing up there, but there are other bugs as well that actually cause the lockup.

I can look into this but I don't think it's as critical as it's made out to be (re comment 6) because I don't think fixing this will fix the dupe. I'd rather see this one taken off the "must get done now" list and put the dupe on that list instead.

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> (In reply to Jason Smith [:jsmith] from comment #11)
> > Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce
> > with APZC disabled?
> 
> I confirmed it with botond. I will confirm it again.

I re-confirmed that when the APZC is disabled, the problem does not happen by using today's master hamachi. And the problem happen when the APZC is enabled.

Comment 15

[Botond Ballo [:botond]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce
> with APZC disabled?

I don't want to put words into Milan's mouth, but my interpretation of comment #8 and comment #10 is: perhaps on an older build it was working even with APZC on, and now it's not, and if so it would be nice to know when it stopped working (with APZC on).

Comment 16

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

I debugged this a little bit. It seems like when we're on the homescreen, the scrollable rect is 560 pixels wide, whereas the screen is only 320 pixels wide (but the homescreen scrolling isn't done with APZC, presumably some homescreen code is taking the touch events and dealing with them). When we fling past a certain velocity, our displayport width becomes 1.5x of the composition bounds, which in this case is 1.5 * 320 = 480 pixels. And because 480 is less than scrollable rect of 560 pixels, the displayport can also shift to the right by up to 80 pixels. When this happens, the left part of the screen is not painted.

When our velocity drops, the displayport width expands to 3.0x of the composition bounds, which is 3.0 * 320 = 960. Because this is wider than the scrollable rect, it just gets clamped down to the entire scrollable rect and the x coordinate is always 0, so this never happens.

The root problem here I believe is that the scrollable rect is being reported as 560 pixels rather than 320 pixels. This wider scrollable rect allows the APZC displayport to shift during flinging.

Comment 17

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

This would probably have started manifesting with bug 907179 because that's when the displayport width multiplier changed to allow this.

Comment 18

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

... and the 560 width seems to be coming from https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/style/dock.css#L12

Changing that to 100% fixes the problem, but obviously makes the dock look squished.

Comment 19

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

Actually this might be better fixed in the APZ code since the homescreen body already has overflow:hidden set on it. I will try that.

Comment 20

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

Attachment: Patch

Comment 21

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

Moving it back to APZ. Sorry for the churn.

Comment 22

[Botond Ballo [:botond]]

Comment on attachment 8368011 [details] [diff] [review]
Patch

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

Looks good. I think we can actually set Axis::mVelocity to 0 if we're overflow:hidden, but we can leave that for a follow-up. (In particular, it doesn't hurt to wait until bug 965871 is fixed before messing around with Axis::mVelocity.)

Comment 23

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/ebab9c016bdf

Comment 24

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

(In reply to Botond Ballo [:botond] from comment #15)
> (In reply to Jason Smith [:jsmith] from comment #11)
> > Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce
> > with APZC disabled?
> 
> I don't want to put words into Milan's mouth, but my interpretation of
> comment #8 and comment #10 is: perhaps on an older build it was working even
> with APZC on, and now it's not, and if so it would be nice to know when it
> stopped working (with APZC on).

Right, and it looks like it probably was around Jan 9-10 that it happened.  Doesn't matter at this point, looks like we have a fix.

Comment 25

[Carsten Book [:Tomcat]]

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

Comment 26

[Ryan VanderMeulen [:RyanVM]]

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