Closed
Bug 1119155
Opened 9 years ago
Closed 6 years ago
[FFOS2.0][Woodduck][SMS]lauch SMS APP from Notification abnormally while view contact form Messaging
Categories
(Firefox OS Graveyard :: Gaia, defect, P2)
Firefox OS Graveyard
Gaia
Tracking
(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.0M affected, b2g-v2.1 affected, b2g-v2.1S affected, b2g-v2.2 affected, b2g-master affected)
RESOLVED
WONTFIX
tracking-b2g | backlog |
People
(Reporter: sync-1, Unassigned)
References
Details
Attachments
(1 file)
23.81 KB,
image/png
|
Details |
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 2•9 years ago
|
||
Norry, could you please help do branch check? Thanks!
Flags: needinfo?(fan.luo)
Comment 3•9 years ago
|
||
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.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0:
--- → affected
status-b2g-v2.0M:
--- → affected
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(ktucker)
Keywords: qawanted
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Comment 4•9 years ago
|
||
Hi Gary, Could you please help to check the problem? Thanks!
Blocks: Woodduck
Flags: needinfo?(fan.luo) → needinfo?(gchen)
Comment 5•9 years ago
|
||
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.
Flags: needinfo?(jelee)
Updated•9 years ago
|
Flags: needinfo?(gchen)
Comment 6•9 years ago
|
||
(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).
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!
Flags: needinfo?(jelee)
Comment 8•9 years ago
|
||
(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.
Flags: needinfo?(jelee)
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!
Flags: needinfo?(jelee)
Comment 10•9 years ago
|
||
(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•9 years ago
|
||
(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?
Flags: needinfo?(jocheng)
Comment 12•9 years ago
|
||
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!
blocking-b2g: --- → backlog
status-b2g-v2.1S:
--- → affected
status-b2g-master:
--- → affected
Flags: needinfo?(jocheng)
Assignee | ||
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Comment 13•6 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•