If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in Firefox 34, Firefox OS v2.1

Status

()

Core
Graphics
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: azasypkin, Assigned: roc)

Tracking

({regression})

unspecified
mozilla34
ARM
Gonk (Firefox OS)
regression
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.1+, firefox33 unaffected, firefox34 verified, b2g-v2.0 unaffected, b2g-v2.1 verified)

Details

Attachments

(4 attachments, 1 obsolete attachment)

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.
Is this a regression? Can the problem be reproduced on desktop firefox on any platforms? Is there a reduced test case?
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.
Keywords: regression
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.
[Blocking Requested - why for this release]:

v2.0 does not have the issue.
blocking-b2g: --- → 2.1?
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → affected
(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.
(Reporter)

Comment 6

3 years ago
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;
* In B2G browser it reproduces what we're seeing in SMS app.
(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?
(Reporter)

Comment 8

3 years ago
Created attachment 8460316 [details]
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.
(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.
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.
Blocks: 1022612
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?
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.
Actually the contents are drawn OK, but the nsDisplayTransform's visible rect is too small. We need to override it when prerendering.
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.
Created attachment 8462496 [details] [diff] [review]
Part 1: Cache prerender flag in nsDisplayTransform
Attachment #8462496 - Flags: review?(tnikkel)
Assignee: nobody → roc
Status: NEW → ASSIGNED
Created attachment 8462497 [details] [diff] [review]
Part 2: Set nsDisplayTransform's visible rect appropriately if we're prerendering it
Attachment #8462497 - Flags: review?(tnikkel)
Created attachment 8462518 [details] [diff] [review]
Part 1: Cache prerender flag in nsDisplayTransform
Attachment #8462518 - Flags: review?(tnikkel)
Attachment #8462496 - Attachment is obsolete: true
Attachment #8462496 - Flags: review?(tnikkel)
Attachment #8462518 - Flags: review?(tnikkel) → review+
Attachment #8462497 - Flags: review?(tnikkel) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/f9c01a0dd048
http://hg.mozilla.org/integration/mozilla-inbound/rev/4d0dce40c8eb
https://hg.mozilla.org/mozilla-central/rev/f9c01a0dd048
https://hg.mozilla.org/mozilla-central/rev/4d0dce40c8eb
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Duplicate of this bug: 1042318
status-b2g-v2.1: affected → fixed
status-firefox33: --- → unaffected
status-firefox34: --- → fixed
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.
blocking-b2g: 2.1? → 2.1+
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
Status: RESOLVED → VERIFIED
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
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1: fixed → verified
status-firefox34: fixed → verified
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.