1122205 - Add a |.cancel()| method to WebActivities

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150115_1128.txt

Description:
When you select an image from an MMS thread you are taken to a larger sized preview of that image. If you are on this screen (or it is open but in a minimized window) when you receive another MMS and select the relevant notification from the notification menu you will be taken to the messenger app but still see the picture preview (with keyboard brought up). If you back out of this picture preview you will be in the new MMS thread. 
This only occurs with picture preview and not with video preview.
It is basically opening the correct MMS thread BEHIND the picture preview.

Repro Steps:
1) Update a Flame to 20150115010229
2) Receive a MMS with a picture attached
3) Go to this MMS and select the picture
4) Receive another MMS from a different sending device (picture optional)
5) Pull down the notification menu and select the MMS notification

Notes: In step 4 the same device as used in step 2 can be used but if you do not minimize the messenger app then the notification will not appear in the notification menu, so using a different device better illustrates the bug.

Actual:
The user is taken back to the picture priview

Expected:
The user will be taken to the appropriate MMS view relevant to the selected MMS notification. 

Environmental Variables:
Device: Flame Master
Build ID: 20150115010229
Gaia: bcc76f93f5659ac1eb8a769167109fd2d7ca4fbd
Gecko: c1f6345f2803
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: 6/6
See attached: logcat

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

This also occurs on 2.2 (V18d-1), 2.2 (V18d), 2.1 (V18d-1), and 2.0 (v18d-1)


Device: Flame Master
Build ID: 20150115010229
Gaia: bcc76f93f5659ac1eb8a769167109fd2d7ca4fbd
Gecko: c1f6345f2803
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

Device: Flame 2.2 (KK - Nightly - Full-Flashed)
Build ID: 20150114002502
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: 748b20315f75
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a2 
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: 20150115002505
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: ce27f2692382
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a2 (Master)
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

Comment 1

[Peter Bylenga [:PBylenga]]

NI on component owner for nomination decision and assignment.  It's not a regression, possibly polish.

Comment 2

[No-Jun Park [:njpark]]

so it sounds like it switches to the appropriate MMS preview, but happens in the background while still seeing the picture preview.  Since it's not a regression, and resolution is relatively straightforward, i don't think it is worth blocking.

Comment 3

[Hermes Cheng (inactive after July 27, 2015)]

No-Jun, do you know which developer is the owner?

Comment 4

[No-Jun Park [:njpark]]

This looks to me the systems front end bug.  Johan, do you know who is the owner of this component?

Comment 5

[Johan Lorenzo [:jlorenzo]]

Naoki is in charge of SystemsFE, redirecting the NI to him. Also, Gregor Wagner is the dev manager of this team.

Comment 6

[Joshua Mitchell (Inactive)]

Added a video of the issue: http://youtu.be/HOT4V0ZjxGs

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I notified gwagner of this bug; I am still keeping the needinfo on me to follow up on this.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hey Michael?  I was wondering if you might be able to take a gander at this please?
It's been happening since 2.0, though I think for UX it might be good to fix.

Comment 9

[Michael Henretty [:mikehenrty][:mhenretty]]

The problem is, right now there is no way for an app to cancel a pending activity. So to fix this we would need to cancel any pending activities whenever a notification was clicked. I'm not sure this is desireable for all cases.

In my mind, the best fix for this would be to allow web activities to be cancelled so that sms could close this activity when it received a click event. This gives apps the most flexibility.

Alive, do you have any thoughts on what we can do here?

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Michael Henretty [:mhenretty] from comment #9)
> The problem is, right now there is no way for an app to cancel a pending
> activity. So to fix this we would need to cancel any pending activities
> whenever a notification was clicked. I'm not sure this is desireable for all
> cases.
> 
> In my mind, the best fix for this would be to allow web activities to be
> cancelled so that sms could close this activity when it received a click
> event. This gives apps the most flexibility.
> 
> Alive, do you have any thoughts on what we can do here?

This is a really interesting and fresh issue!

After thinking, as you said, cancelling the web activity programatically is a general solution to go.
Let's seek Fabrice's help or he might be able to advise more because he wrote most web activity gecko implementation.

Fabrice, do you think this is do-able and something we should do?

Comment 11

[[:fabrice] Fabrice Desré]

Yep, interesting use case! I think we can add a cancel() method to https://mxr.mozilla.org/mozilla-central/source/dom/webidl/MozActivity.webidl#15
The tricky part will be to get everything in place to let gaia know which frame to close.

Comment 12

[Hermes Cheng (inactive after July 27, 2015)]

[Blocking Requested - why for this release]:
Based on previous discussion, I think it is a new feature for web activity. Besides, it is also required for better user experience. Nominate this bug as a 3.0 blocker for following actions.

Comment 13

[Gregor Wagner [:gwagner]]

For product triage.

Comment 14

[Julien Wajsberg [:julienw]]

[Blocking Requested - why for this release]:
blocks 2.5+ bug 1149345

We need a way to cancel an existing activity from the initiating app.

Comment 15

[Ravi Dandu]

Given the User Experience impact of this, we should get it into 2.5.

Comment 16

[Gregor Wagner [:gwagner]]

Not a blocker based on our blocking criteria. We can add it to the feature-b2g list.

Comment 17

[Julien Wajsberg [:julienw]]

Gregor, then please remove the blocking statu from bug 1149345 as well.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

I don't think we need to spend time on this; closing