1042104 - [B2G][Messages] App panel that's sliding in is not visible during transition

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Oleg Zasypkin [:azasypkin]]

Target panel is hidden during css transition when navigating between panels in SMS app.

STR:
1. Open SMS app;
2. Tap on "New message" button;
3. Observe "New message" panel sliding in from the right side.

Expected result:
* Both panels should be visible during transition (inbox panel that's sliding out and "new message" panel that's sliding in);

Actual result:
* Panel that's sliding out is visible during transition, panel that's sliding in is not (observe white container background instead). Target panel becomes visible only at the end of transition.

Reproduced on the latest master PVT build for Flame.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Is this a regression? Can the problem be reproduced on desktop firefox on any platforms? Is there a reduced test case?

Comment 2

[Julien Wajsberg [:julienw]]

I did a manual regression using builds from PVT:

build 2014-07-20-16-02-02: works
build 2014-07-21-04-02-10: fails

We also tried an old gaia with current gecko, and the failure is still here, so this is a gecko regression.

gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e9cdcf646d1c&tochange=42c6a5418370

Scary bug 1022612 is in this range, but others too, so we may need a finer regression window.

Comment 3

[Julien Wajsberg [:julienw]]

I don't see the exact same issue in Nightly but I see an issue that could be related, both in the SMS app and in the browser's chrome:

1. click the hamburger menu icon
2. click the "?" icon

=> The menu is not refreshed properly while it's sliding.

Comment 4

[Julien Wajsberg [:julienw]]

[Blocking Requested - why for this release]:

v2.0 does not have the issue.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(In reply to Julien Wajsberg [:julienw] from comment #2)
> I did a manual regression using builds from PVT:
> 
> build 2014-07-20-16-02-02: works
> build 2014-07-21-04-02-10: fails
> 
> We also tried an old gaia with current gecko, and the failure is still here,
> so this is a gecko regression.
> 
> gecko pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=e9cdcf646d1c&tochange=42c6a5418370
> 
> Scary bug 1022612 is in this range, but others too, so we may need a finer
> regression window.

Yeah getting a tighter regression range is probably pretty important for pin pointing this.

Comment 6

[Oleg Zasypkin [:azasypkin]]

Attachment: Test case

Ok, here is the reduced test case:

* In Firefox Nightly it behaves differently, but still rendering is not correct;
* In B2G browser it reproduces what we're seeing in SMS app.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #6)
> Created attachment 8460312 [details]
> Test case
> 
> Ok, here is the reduced test case:
> 
> * In Firefox Nightly it behaves differently, but still rendering is not
> correct;

What incorrectness do you see in Nightly?

Comment 8

[Oleg Zasypkin [:azasypkin]]

Attachment: Weirdness in Firefox Nightly

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #6)
> > Created attachment 8460312 [details]
> > Test case
> > 
> > Ok, here is the reduced test case:
> > 
> > * In Firefox Nightly it behaves differently, but still rendering is not
> > correct;
> 
> What incorrectness do you see in Nightly?

Please, see how text is rendered.

Comment 9

[Julien Wajsberg [:julienw]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #6)
> > Created attachment 8460312 [details]
> > Test case
> > 
> > Ok, here is the reduced test case:
> > 
> > * In Firefox Nightly it behaves differently, but still rendering is not
> > correct;
> 
> What incorrectness do you see in Nightly?

When clicking once, the text on the left is not painted until the transition is finished.
Then clicking twice, the text on the right seems to be painted once, but not correctly.

Comment 10

[Oleg Zasypkin [:azasypkin]]

The first tinderbox build where the issue is reproduced is:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux64/1405778119/

mozilla-inbound revision: https://hg.mozilla.org/integration/mozilla-inbound/rev/24a69de91baa

So "patch 46" for bug 1022612 is likely culprit.

Comment 11

[Julien Wajsberg [:julienw]]

Not "patch 46" because the previous build is from the revision https://hg.mozilla.org/integration/mozilla-inbound/rev/9350909a3401 

=> http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9350909a3401&tochange=24a69de91baa

So this is one of the patch in bug 1022612 for sure. Not sure if it makes sense to bisect this though?

Comment 12

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

I suspect what's happening here is that we're prerendering the element but we're not using the full area of the element for visibility and drawing calculations, so we "prerender" only the visible content of the element, i.e. just the colored background and not the text.

Comment 13

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

Actually the contents are drawn OK, but the nsDisplayTransform's visible rect is too small. We need to override it when prerendering.

Comment 14

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

To be precise, the visible region of the ContainerLayer is computed incorrectly, without taking into account prerendering. This would manifest with OMTAnimation, but it also manifests without it, when we avoid doing a full layer tree update and just set the transform on a layer.

Comment 15

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

Attachment: Part 1: Cache prerender flag in nsDisplayTransform

Comment 16

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

Attachment: Part 2: Set nsDisplayTransform's visible rect appropriately if we're prerendering it

Comment 17

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

Attachment: Part 1: Cache prerender flag in nsDisplayTransform

Comment 18

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

http://hg.mozilla.org/integration/mozilla-inbound/rev/f9c01a0dd048
http://hg.mozilla.org/integration/mozilla-inbound/rev/4d0dce40c8eb

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f9c01a0dd048
https://hg.mozilla.org/mozilla-central/rev/4d0dce40c8eb

Comment 21

[bhavana bajaj [:bajaj]]

Switching the 2.1?->2.1+, on these fixed bugs as these are regression.

Nothing to land here, its just flag-cleanup of 2.1? list. Please Ni me if there is confusion/disagreement.

Comment 22

[No-Jun Park [:njpark]]

Verified that this fix is in 2.1

Version Info;
Gaia-Rev        7e2e65a9668123b54c8cce5dacfdba6f4bd4672b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/2325da834971
Build-ID        20141014001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141014.034809
FW-Date         Tue Oct 14 03:48:20 EDT 2014
Bootloader      L1TC00011840

Comment 23

[Duane Dixon [:ddixon]]

Issue is verified fixed in Flame 2.2, 2.1 Aurora, 2.1 Firefox34

Actual Results: Slide transition to the 'new message' page functions correctly. 

Device: Flame Master
Build ID: 20141014040203
Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f
Gecko: 54217864bae9
Version: 36.0a1 (Master)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1 (firefox34) 
Build ID: 20141014001201
Gaia: 7e2e65a9668123b54c8cce5dacfdba6f4bd4672b
Gecko: 2325da834971
Version: 34.0 (2.1)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.1 (Aurora) 
Build ID: 20141013000205
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: ad497694e258
Version: 34.0a2
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0