Closed Bug 1042104 Opened 5 years ago Closed 5 years ago
[B2G][Messages] App panel that's sliding in is not visible during transition
1.48 KB, text/html
120.61 KB, image/png
6.50 KB, patch
|Details | Diff | Splinter Review|
12.01 KB, patch
|Details | Diff | Splinter Review|
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.
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.
(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.
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?
(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.
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.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #8462518 - Flags: review?(tnikkel) → review+
Attachment #8462497 - Flags: review?(tnikkel) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Duplicate of this bug: 1042318
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?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.