Joshua Mitchell (Inactive) Reporter
	Description • 9 years ago

Description:
When tapping on a screenshot notification in the notification menu a preview of the screenshot is brought up. When you are in a phone call and on the callscreen the screenshot is brought up behind the callscreen and the user will not be able to see it until the call is ended and the callscreen goes away. If the user were to tap on the screenshot notification and then minimize (go to homescreen) the callscreen by hitting the homescreen button then the image will be seen briefly and then close as well. If the user were to minimize the callscreen first and then select the screenshot notification they are properly taken to the screenshot. Tapping on the screenshot notification banner (as opposed to in the notification menu) repros the same in respective areas. 

Notes: Tapping on other type of notifications will bring up the proper screens (example: SMS notifcations, 

Repro Steps:
1) Update a Flame to 20150113010202
2) Receive or make a phone call and be on the callscreen
3) Take a screenshot to propagate a screenshot notification (this can be done previously)
4) Pull down the notification menu and tap on the screenshot notification. 

Actual:
User is not taken to the picture view page (screenshot actually opens BEHIND the callscreen)

Expected:
User will be taken to the screenshot

Environmental Variables:
Device: Flame Master
Build ID: 20150113010202
Gaia: 9946a490a9264b42e65385d703b28fa055ab2d42
Gecko: 3d846527576f
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 38.0a1 (Master)
Firmware Version: V18d-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 9/9

See attached: logcat

-----------------------------------------------------------------------------------------------

This issue also repros on Flame 2.2 (V18d), 2.2 (v18d-1), 2.1 (v18d-1) and 2.0 (v18d-1)

Device: Flame 2.2 (KK - Nightly - Full-Flashed)
Build ID: 20150112010228
Gaia: f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko: bb8d6034f5f2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 
Firmware Version: V18d-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.2 (KK - Nightly - Full-Flashed)
Build ID: 20150112010228
Gaia: f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko: bb8d6034f5f2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 
Firmware Version: V18d
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (KK - Nightly - Full-Flashed)
Build ID: 20150113001255
Gaia: 836e6d74cb8b7016df555f85445893b3ff9aac12
Gecko: 074f79a929d2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware Version: V18d-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (KK - Nightly - Full-Flashed)
Build ID: 20150113000203
Gaia: 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko: c6fd5db59e0e
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 32.0 (2.0)
Firmware Version: V18d-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Peter Bylenga [:PBylenga]
	Comment 1 • 9 years ago

QAWanted to see if this is a regression across base images.

	Sue
	Comment 2 • 9 years ago

This issue can be repro on Flame 2.2 with v188 base image. Tap on the screenshot notification, user is taken to the callscreen, after the call ended, user will be taken to the screenshot.
See attachment:video.MP4 and logcat_2052.txt

Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/748b20315f75
Build-ID        20150113162504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.194114
FW-Date         Tue Jan 13 19:41:25 EST 2015
Bootloader      L1TC00011880

	Sue
	Comment 4 • 9 years ago

This issue can be repro on Flame 2.0/2.1 with v188 base image.

Flame 2.0 build(v188):
Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f2b6017e84eb
Build-ID        20150113160201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.192825
FW-Date         Tue Jan 13 19:28:37 EST 2015
Bootloader      L1TC00011880

Flame 2.1 build(v188):
Gaia-Rev        6957ac8a322234ec99c8abb7cc18dc6a2e0176db
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6600eba54256
Build-ID        20150113161204
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.192836
FW-Date         Tue Jan 13 19:28:47 EST 2015
Bootloader      L1TC00011880

	Peter Bylenga [:PBylenga]
	Comment 5 • 9 years ago

NI on component owner for nomination decision and assignment.

	Gerry Chang [:gchang]
	Comment 6 • 9 years ago

I think this is an enhancement. NI UX for more information.

	Jenny Lee
	Comment 7 • 9 years ago

Redirect the needinfo to Carrie =)

	Gerry Chang [:gchang]
	Comment 8 • 9 years ago

Please ignore comment #6. Sorry for putting the wrong comment #6. This is a bug, need developer for more information.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 9 • 9 years ago

Technical view: the inline activity is under the callscreen because we didn't think callscreen will invoke an activity before. There are two possible solution here:
* Always hide the callscreen once there is an activity-request.
* Put the inline activityWindow inside CallscreenWindow/AttentionWindow - the problem is that it will hide with Callscreen when pressing home button, hence you will see strange transition.

Ni etienne to see his opinion.

	Etienne Segonzac (:etienne)
	Comment 10 • 9 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #9)
> Technical view: the inline activity is under the callscreen because we
> didn't think callscreen will invoke an activity before. 

Well the callscreen is not invoking the activity here, the system app is [1].
(when tapping on the screenshot notification)

> There are two
> possible solution here:
> * Always hide the callscreen once there is an activity-request.

Sounds about right.


[1] https://github.com/mozilla-b2g/gaia/blob/70922d07e1de10aea3381aa954add71ce75c2e2d/apps/system/js/screenshot.js#L154-161

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 11 • 9 years ago

(In reply to Etienne Segonzac (:etienne) from comment #10)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #9)
> > Technical view: the inline activity is under the callscreen because we
> > didn't think callscreen will invoke an activity before. 
> 
> Well the callscreen is not invoking the activity here, the system app is [1].
> (when tapping on the screenshot notification)

We don't actually know who is. (anchor link is called inside Gecko but definitely invoked by top most window)
If the caller is the system, it might be the system or the top most window.
If the caller is not system, usually it's true to treat top most window is the real caller.

	Hermes Cheng (inactive after July 27, 2015)
	Comment 12 • 9 years ago

(In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #9)
> Technical view: the inline activity is under the callscreen because we
> didn't think callscreen will invoke an activity before. There are two
> possible solution here:

NI designer to see his opinion for these solutions

> * Always hide the callscreen once there is an activity-request.
> * Put the inline activityWindow inside CallscreenWindow/AttentionWindow -
> the problem is that it will hide with Callscreen when pressing home button,
> hence you will see strange transition.
> 
> Ni etienne to see his opinion.

	Eric Pang [:epang] UX
	Comment 13 • 9 years ago

(In reply to Hermes Cheng[:hermescheng] from comment #12)
> (In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #9)
> > Technical view: the inline activity is under the callscreen because we
> > didn't think callscreen will invoke an activity before. There are two
> > possible solution here:
> 
> NI designer to see his opinion for these solutions
> 
> > * Always hide the callscreen once there is an activity-request.
> > * Put the inline activityWindow inside CallscreenWindow/AttentionWindow -
> > the problem is that it will hide with Callscreen when pressing home button,
> > hence you will see strange transition.
> > 
> > Ni etienne to see his opinion.

If I'm understanding option one correctly I think it's the way to go (Always hide the callscreen once there is an activity-request.)

As a user I would expect the preview of the screenshot to overlay the callscreen when tapped from the notification tray.  Once the user presses the back arrow they should be returned to the call screen.  If the user presses the home button they should return to be home then use the notification tray to return to their active call.

I feel like this might be more of an ixd question so I would like Rob's feedback as well. But also flagging Jacqueline since I know Rob is busy for the next couple of weeks. Thanks!

	Jacqueline Savory [:jsavory] UX
	Comment 14 • 9 years ago

I agree with Eric's proposal, if the user is actively trying to view the screenshot then it should not be hidden by the callscreen. I also agree that the back button should return to the call while the home button will remain consistent and return to the homescreen.

	Hermes Cheng (inactive after July 27, 2015)
	Comment 15 • 9 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #9)
> Technical view: the inline activity is under the callscreen because we
> didn't think callscreen will invoke an activity before. There are two
> possible solution here:
> * Always hide the callscreen once there is an activity-request.
It seems we choose this one as our solution.
> * Put the inline activityWindow inside CallscreenWindow/AttentionWindow -
> the problem is that it will hide with Callscreen when pressing home button,
> hence you will see strange transition.
> 
> Ni etienne to see his opinion.

nominate as a blocker since bad user experience.

	bhavana bajaj [:bajaj]
	Comment 16 • 9 years ago

(In reply to Hermes Cheng[:hermescheng] from comment #15)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #9)
> > Technical view: the inline activity is under the callscreen because we
> > didn't think callscreen will invoke an activity before. There are two
> > possible solution here:
> > * Always hide the callscreen once there is an activity-request.
> It seems we choose this one as our solution.
> > * Put the inline activityWindow inside CallscreenWindow/AttentionWindow -
> > the problem is that it will hide with Callscreen when pressing home button,
> > hence you will see strange transition.
> > 
> > Ni etienne to see his opinion.
> 
> nominate as a blocker since bad user experience.

I don't think this is a new regression and the sound of this solution feels risky to me, so not blocking If we end up having a low risk patch I am happy to consider uplift depending on risk/reward at that point for 2.2

	BMO Automation
	Comment 17 • 6 years ago

Firefox OS is not being worked on