User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 Steps to reproduce: Pre-condition: Card View - Kill all apps. STR - 1. Call to flame (v2.0) 2. disconnect the call by tapping red (disconnect call) button. 3. Enter card view. 4. Dialer app is seen. Actual results: It is seen black Expected results: should be seen normal

My observation : Card view was normal before this landed - https://bugzilla.mozilla.org/show_bug.cgi?id=1062136. Sorry, I didn't check the behaviour on 2.1 or 2.2. It is reproducible on Flame v2.0

Can we confirm these STR for 2.0? I'll look at 2.1 and master but if QA is able to give any input on those branches that would help too.

Let's wait on QA to see if 2.1 exhibits the same behavior. Otherwise we're just trading one problem for another by backing out bug 1062136 if it is indeed the cause of this possible regression, it could also be a regression in getting the screenshot in gecko itself.

In both master and 2.1 I dont get the dialer at all in cards vie: 1. In Flame/2.1, open an app - I used browser and camera with the same result 2. Call the Flame/2.1 3. Accept call in Dialer 4. Long-press home button to get the task manager/card view Expected: Dialer shows my active call as the first card and tapping on it returns me to the active call Actual: App from step 1 is the first card. The dialer app is not shown (unless it was already open before step 1) The only way to get back to the call is to pull down the utility tray and click the 'call' entry there

Tested with Shallow Flash on 319mb using Engineering builds This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK, Flame 2.0 Base Actual Results: Bringing up card view when on a call recieved during another app active wil not show the Dialer as a running app. Repro Rate: 4/4 Environmental Variables: Device: Flame 2.2 KK BuildID: 20141111042605 Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184 Gecko: c60fc2c11c0e Version: 36.0a1 (2.2) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.1 KK BuildID: 20141111072405 Gaia: 4c159e75a1568afbbf0c83c1235ec56facfbe87d Gecko: d1930a36f9c3 Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.0 KK BuildID: 20141110175151 Gaia: dfdd6268b9784eafdd509f0ddf71407698ed5080 Gecko: fcc5d31f84d7 Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.0 Base BuildID: 20141021162107 Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8 Version: 32.0 (2.0) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

(In reply to Cody Roesch [:croesch] from comment #5) > Tested with Shallow Flash on 319mb using Engineering builds > > This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 > KK, Flame 2.0 Base If this repro's back to v2.0, I wonder if it is a bug at all. Can you confirm the expected behavior Francis or Rob?

> If this repro's back to v2.0, I wonder if it is a bug at all. Can you > confirm the expected behavior Francis or Rob? I mean the issue described in comment #4.

Hi Sam, I would expect the behaviour to be as you describe in comment #4. Also, if the user taps on the dialer icon during a call, this should also return the user to the current call. However, I suspect that you're right and that neither of these things have historically been the case. The incoming call dialog has always been a strange view that isn't attached to an app. We used to have a big banner that let users switch back to the current call, and that papered over the cracks from a UX POV. But now that we don't, we should make it easier for users to switch back to a call. I'll let Carrie confirm what the behaviour should be since this is a Dialer issue.

Hi, I agree on the expected results described in comment 4. I think it's another way to allow users get back to the call. And actually, we did open the dialer APP at that point. So it make sense the page appears in task manager. Thanks!

I'm worried this bug confuses two potential issues. It seems like the callscreen not being in the task manager is a known, expected behavior that we want to fix for 2.2. I've opened bug 1098443 to track that. The original issue - card view is black for system message launched background app - I've just reproduced that on 2.0: STR: Flame/2.0 Decline incoming call Long press on home button to bring up task manager Expected: Either the dialer app doesn't show up at all, or it shows a screenshot of the dialer Actual: The 'Dialer' card is completely black Does *not* reproduce on 2.1 The same is true if you accept the call and then complete it. It doesn't seem to be timing sensitive - if you wait a few seconds after the call screen disappears before showing task manager, you still get the black screen.

I'm removing affected flags for 2.1, 2.2, we are tracking that issue tested in comment #5 in bug 1098443

sigh, clearing all these flag I set by accident. Sorry for the confusion folks.

Is this still an issue or can it be closed? Thanks!

Hi Tiffanie, This current bug doesn't occur on latest build of Flame KK 2.5&2.6 and Aries KK 2.5&2.6 by the STR in comment 0 or comment 10. Actual results: The app preview in card view shows normally, and isn't shown as black screen after ending the call. See attachment: Flame_v2.6.3gp Reproduce rate: 0/10 Note: Sometimes there is little problem that the black screen flashes for a second and then Dialer preview screen shows normally in card view after you quickly end the call. ----------------------------------------------------------------------------- Device: Flame KK 2.5 512mb Build ID 20151119010236 Gaia Revision 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5 Gaia Date 2015-11-17 07:35:12 Gecko Revision http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/afcf8a4b4cf310edd0e442fa80506d5cce291666 Gecko Version 44.0a2 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151119.001411 Firmware Date Thu Nov 19 00:14:20 UTC 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Flame KK 2.6 (master) 512mb Build ID 20151119150204 Gaia Revision 94a821b49f4dca3f9321cd80e13c44c4a6696952 Gaia Date 2015-11-19 15:35:33 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/cc325db44f6f8a58604d60b746c140e73f3d8216 Gecko Version 45.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20151119.182720 Firmware Date Thu Nov 19 18:27:32 EST 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Aries KK 2.5 Build ID 20151119010651 Gaia Revision 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5 Gaia Date 2015-11-17 07:35:12 Gecko Revision http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/afcf8a4b4cf310edd0e442fa80506d5cce291666 Gecko Version 44.0a2 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151119.001315 Firmware Date Thu Nov 19 00:13:23 UTC 2015 Bootloader s1 Device: Aries KK 2.6 (master) Build ID 20151118150439 Gaia Revision cba7e4b86361af31b153cfebaf99900e0b860f7b Gaia Date 2015-11-18 09:45:49 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/1d6155d7e6c91fa5ec1ef6927f3d3a044187896d Gecko Version 45.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151118.142334 Firmware Date Wed Nov 18 14:23:42 UTC 2015 Bootloader s1

cc :mcav so he's aware of the polish nit in Comment #14, but I think we can close this

Removing NI as Sam closed the bug in previous comment. Thanks Shally!