Closed Bug 964997 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Panning and Zooming, defect)

28 Branch
ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla29
blocking-b2g 1.3+
Tracking Status
firefox27 --- wontfix
firefox28 --- fixed
firefox29 --- fixed
b2g-v1.3 --- fixed
b2g-v1.4 --- fixed

People

(Reporter: sotaro, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(2 files)

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.
blocking-b2g: --- → 1.3?
The problem does not happen when APZC is disabled.
Duplicate of this bug: 965077
Blocks: gaia-apzc
Keywords: regression
Please review for APZC
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(bugmail.mozilla)
Preeti, even with "it is really hard to reproduce", we're considering this a 1.3 blocker?
Flags: needinfo?(praghunath)
(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.
> 
> 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.
Blocks: 942267
Let's find the regression window and then take a look at what caused this.
(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.
(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.
Sotaro - Can you clarify comment 2? Did you confirm this doesn't reproduce with APZC disabled?
Flags: needinfo?(sotaro.ikeda.g)
(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.
Flags: needinfo?(sotaro.ikeda.g)
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.
Flags: needinfo?(bugmail.mozilla)
(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.
(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).
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.
This would probably have started manifesting with bug 907179 because that's when the displayport width multiplier changed to allow this.
... 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.
Component: Panning and Zooming → Gaia::Homescreen
Product: Core → Firefox OS
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.
Attachment #8368011 - Attachment description: 1-fling-41e6745 → Patch
Attachment #8368011 - Attachment is patch: true
Attachment #8368011 - Flags: review?(botond)
Moving it back to APZ. Sorry for the churn.
Assignee: nobody → bugmail.mozilla
Component: Gaia::Homescreen → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → 28 Branch
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.)
Attachment #8368011 - Flags: review?(botond) → review+
(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.
https://hg.mozilla.org/mozilla-central/rev/ebab9c016bdf
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Duplicate of this bug: 964359
You need to log in before you can comment on or make changes to this bug.