1119155 - [FFOS2.0][Woodduck][SMS]lauch SMS APP from Notification abnormally while view contact form Messaging

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect, P2)

Description

[sync-1]

Created an attachment (id=1100293)
 Press several times to cancel
 
 DEFECT DESCRIPTION:
 lauch SMS APP from Notification abnormally while view contact form Messaging
 
  REPRODUCING PROCEDURES:
 1.into Messaging list, select one conversation to enter, and the recipient stored in contact
 2.type some text(must do this);
 3.view contact by touch conversation title;
 4.stay on this screen, receive a new message;
 5.read the new message from status bar notification; MS can't turn to read the new message;
 6.do step 5 several times, turn back screen from contact to messaging, a prompt warning menu show, and you must press "OK" or "Cancel" several times to back to messaging screen.
 
  EXPECTED BEHAVIOUR:
 5.step 5, MS should turn to read the new message with warning text screen;
 6.step 6, MS should not need to press several times to cancel the prompt menu.
 
 ->61405
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: Press several times to cancel

Comment 2

[Peipei Cheng (needinfo if you need my action)]

Norry, could you please help do branch check? Thanks!

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

We can help on branch checking on Flame.

Issue reproduces on Flame 2.0, Flame 2.1, Flame 2.2, and base image v188-1 (v2.0).

Observed behavior: Following STR, user is unable to be brought to the new message (received from a different sender than step 1) via tapping on notification. Step 6 behavior was observed as well. This whole bug seems to be that the view contact screen is obscuring what's supposed to be going on, so all the actions starting from step 5 onwards are being done on underneath that screen.

Tested in shallow flash and 319MB memory.

Device: Flame 2.0
BuildID: 20150109060358
Gaia: 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko: 6589b217ba71
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.1
BuildID: 20150109061601
Gaia: 64db236bea9a0510567ab7ced2f2b4688737123c
Gecko: 44874e713ddf
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master
BuildID: 20150109114631
Gaia: 2c7d14040149e1f9b1bb3972ff150be0472fa6b6
Gecko: 86396560012
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

-----

Since this was filed under 2.0M, I'm regarding this branch check as completed and marking the tracking flags as so.

Comment 4

[Josh Cheng [:josh]]

Hi Gary,
Could you please help to check the problem? Thanks!

Comment 5

[Luke Chang [:lchang] (inactive)]

The root cause is that the SMS app is covered by its activity window (contacts app) in the 5th step in comment 0. Users can't see its change although the SMS app indeed does what it should do at that moment. It's also the reason why we'll see multiple confirm dialogs in the 6th step after clicking the notification several times.

After discussing with Steve, the behavior before is that the system app will force close all the activity windows after its parent app is set to background but it has been changed since v2.1.

I'm not sure if it's a good idea to force close all the activity windows as well when a user clicks a notification which is from its parent app. The risk should be low since we've already done like this in v2.0 branch. However, we may also need to figure out why we don't do this anymore in v2.1.


Hi Jenny,

Could you please give us some feedback about this? Thanks a lot.

Comment 6

[Luke Chang [:lchang] (inactive)]

(In reply to Luke Chang [:lchang] from comment #5)
> After discussing with Steve, the behavior before is that the system app will
> force close all the activity windows after its parent app is set to
> background but it has been changed since v2.1.

Sorry, it should be changed since v2.0 (after bug 916709 is landed).

Comment 7

[Jenny Lee]

Hi Luke,

As I was trying to reproduce the issue today, I found out that when staying on "view contact" or "create new contact" page, incoming new message notification won't appear on screen at all (notification sound was played). Has there been any change to it? Let me know, thanks!

Comment 8

[Luke Chang [:lchang] (inactive)]

(In reply to sync-1 from comment #0)
>  1.into Messaging list, select one conversation to enter, and the recipient
> stored in contact
>  4.stay on this screen, receive a new message;

Hi Jenny,

I found that the sender of the thread we select to view (step 1) must be different from one of the new message (step 4). The notification won't appear if we've already stayed in the same thread.

Comment 9

[Jenny Lee]

Hi Luke and Steve,

Per discussion with Harly, to tackle the root cause of this bug, which is the use of activity window, we need to make a system level change (that is to call app directly instead of using activity window). However this is unlikely to happen at current stage.

The best way to handle this problem would be force close activity window (as you mentioned in comment 5), and do auto save for the draft. So the flow would be:  

 1.into Messaging list, select one conversation to enter, and the recipient stored in contact
 2.type some text(must do this);
 3.view contact by touch conversation title;
 4.stay on this screen, receive a new message;
 5.tap the new message notification; 
 6.close "view contact" and save the draft automatically, go to the new message and display a toast that says "Draft saved".

I realize the proposed solution might have some implementation limitation and auto save is pretty much a new feature, we can have a f2f discussion on this. Thanks!

Comment 10

[Luke Chang [:lchang] (inactive)]

(In reply to Jenny Lee from comment #9)
>  6.close "view contact" and save the draft automatically, go to the new
> message and display a toast that says "Draft saved".

The current behavior is that SMS app will prompt "Discard the message you're composing and open the new message?" when a user click the new message notification during composing a new message. So, maybe we can prompt the same message after closing the "view contact" in step 6 so that we can defer the implementation of auto save feature.

However, to close an activity window by app itself may be another challenge. Let's discuss it offline tomorrow.

Comment 11

[Luke Chang [:lchang] (inactive)]

(In reply to Luke Chang [:lchang] from comment #10)
> (In reply to Jenny Lee from comment #9)
> >  6.close "view contact" and save the draft automatically, go to the new
> > message and display a toast that says "Draft saved".
> 
> The current behavior is that SMS app will prompt "Discard the message you're
> composing and open the new message?" when a user click the new message
> notification during composing a new message. So, maybe we can prompt the
> same message after closing the "view contact" in step 6 so that we can defer
> the implementation of auto save feature.

After offline discussion with Steve and Jenny, we agreed to try above solution at current stage.


Hi Josh,

Since this bug is not a blocker, should we fix it on v2.0m or put it in backlog?

Comment 12

[Josh Cheng [:josh]]

Hi Luke,
I think we can postpone the fix as we should focus on more serious issues. I will put this to backlog and wait for more complete solution.

Thank you very much!

Comment 13

[BMO Automation]

Firefox OS is not being worked on