Steps to reproduce: 1. Open browser 2. Select options icon 3. Select Share -> Email 4. Once in email compose, press back arrow in header Result: Transition from compose email screen back to browser is glitchy. Screen darkens and there is a slight pause in the middle of the slide transition. Expected: There should be a smooth screen slide transition back to browser and the screen should not darken.

Glitches gives an impression of bad performance and low quality. This is not what you expect from Firefox OS. Please fix.

Can QA help try this on branches (2.0,2.1,2.2) and check if this is reproducible and/or a regression ?

This issue occurs on Flame 2.1 and Flame 2.2. Observed behavior: Screen turns dark for the duration of the transition and the animation has a slight pause while transitioning back to Browser via the back button on email composing screen. Repro rate: on 2.1: 3/3 on 2.2: 3/3 Device: Flame (shallow flash, 319MB mem) BuildID: 20141015143144 Gaia: 477a9e61c3edf12f32a62a19d329cd277202cc6b Gecko: 67573e422a0f Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame (shallow flash, 319MB mem) BuildID: 20141016070843 Gaia: 5c636a7a54b2c86d8ff6bc1aa1e5f9594c7bc586 Gecko: 77f3ca1fe052 Version: 36.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 ----- This issue seems less severe in Flame 2.0 and Flame v180 base only. The transition animation seems smooth (no pause) and it seems faster than 2.1/2.2, but screen DOES turn dark during transition. Marking 2.0 as affected for now. Device: Flame 2.0 BuildID: 20141016063743 Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00 Gecko: e2ad5b580ebc Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Olof, thanks for letting us know your concerns, I will let Joe comment further on triaging / blocking against 2.1.

Can we get a video here to understand the impact. Tony tried this but didn't see this across every share so not sure how severe this is, so a video will definitely help. In parallel, requesting :asutherland to help start with investigation as well, given this happens during the transition in email.

I checked from the email side, as :asuth has low availability at the moment: Email uses "disposition": "window" for the share activity, not "inline", so that could be why it may show up for email vs some other app that uses "inline" instead. I tried with the Messages app, and it has a different animation behavior, and its disposition is "inline". For 2.1 consideration, it is not feasible to consider "inline" for email due to how the worker is used to communicate with the IndexedDB, it would be quite a bit of plumbing work to get an "inline" flow to work. Some historical background is in bug 802643, but that may be going too far back. I confirmed with a quick hack to see if part of the issue was email doing extra work during the transition. I tried the following: * Open https://openstandard.mozilla.org/ in the browser * Select share, choose email * On compose, press back button I see a bit of a confusing back slide animation with a fade in, but do not really see a slight pause, just a bit of a disjointed awkward transition. I commented out the other code in the "Back" operation in email, just do a postError back, and it did not seem to affect the animation. So from what I can tell so far, I would think this is more of an inter-app transition tuning issue, and not anything specific email is doing, expect perhaps the use of disposition: window. Happy to look more if video or further investigation points to some experiments to try in email.

Not blocking per triage this morning. James, let's determine if this belongs in the email backlog. From your comment #6, it looks like this may belong to another team. Thanks!

Stephany: correct, the system app/window management team should take a first look at the transition, as it may be generic to any disposition: window apps, and the transition may just need generic modification for all those types of apps. I will move the bug that group to get their eyes on it, but can be moved around later as needed.

talked to Olof and agreed that window management changes are not simple and we need to take some time to review this item and we should look this for followup release and not in 2.1

Firefox OS is not being worked on