Closed Bug 1205988 Opened 9 years ago Closed 9 years ago

[Messages]Enter Messaging Settings view, then device receives a MMS, but it can't back to Messages view when user taps the notification.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.2 unaffected, b2g-master affected)

RESOLVED DUPLICATE of bug 1190613
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- affected

People

(Reporter: qiutian, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [2.5-aries-test-run-2])

Attachments

(2 files)

Attached file logcat_message.txt.txt
[1.Description]: [AriesKK_v2.5][FlameKK_2.5]Launch Messages, tap "..." and select Settings. Then device receives a MMS, after tapping the reminder on the Notification tray , the reminder still exists in Notification tray and it can't switch to message conversation. Tap "<" icon, observe conversation view and tap back, the "back" button is not available. Found at:13:17 See attachment:logcat_message.txt, AriesKK_V2.5_message.3gp. [2.Testing Steps]: 1.Launch Messages. 2.Tap "..." and select Settings. 3.Receive a MMS. 4.Tap the reminder on the Notification tray. 5.Tap "<" icon. 6.Observe conversation view and tap back. [3.Expected Result]: In step 4, the notification will disappear from notification bar and it should switch to message conversation. In step 6, the "back" button work well, device will back to Messages view. [4.Actual Result]: In step 4, the notification still shows in Notification tray, and it can't switch to message conversation. In step 6, the "back" button is not available. [5.Reproduction build]: Device: Aries KK 2.5 [Affected] Build ID 20150917232610 Gaia Revision 2082894c8e974b0c371e4dec298e0ad0f3ac56b1 Gaia Date 2015-09-17 14:56:47 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/01a75ffad1024a3f75d494fb77a022c96a497eb2 Gecko Version 43.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150917.224608 Firmware Date Thu Sep 17 22:46:16 UTC 2015 Bootloader s1 Device: Flame KK 2.5[Affected] Build ID 20150917150223 Gaia Revision aede8622d780ec71f766a3ecccbff74c04aaba4e Gaia Date 2015-09-17 03:40:46 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/3929b8fc6c33bf9cc80299743063f0981f545452 Gecko Version 43.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150917.183330 Firmware Date Thu Sep 17 18:33:40 EDT 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Flame 2.2[Unaffected] Build ID 20150917032502 Gaia Revision 047c85de3fa1633bd0a319e40bffd2d5afcdae1d Gaia Date 2015-09-16 13:33:06 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1db31b873e29 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150917.065532 Firmware Date Thu Sep 17 06:55:44 EDT 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test
For the "In step 4, the notification still shows in Notification tray, and it can't switch to message conversation." - it looks like a dupe of bug 1122205 or bug 1149345, we need activity.cancel to solve this. This part is not regression, we had this behavior for a long time already. As for "In step 6, the "back" button is not available." - sounds interesting, wondering if it can be related to bug 1203886 - going to do a quick check.
Flags: needinfo?(azasypkin)
(In reply to Oleg Zasypkin [:azasypkin][⏰UTC+1] from comment #2) > For the "In step 4, the notification still shows in Notification tray, and > it can't switch to message conversation." - it looks like a dupe of bug > 1122205 or bug 1149345, we need activity.cancel to solve this. This part is > not regression, we had this behavior for a long time already. Okay, there is still a difference in behavior in v2.5 and v2.2 - when user taps on notification in v2.2, we "silently" open Conversation view (user still sees Activity app and doesn't see that Messages app view has changed) and remove notification, in v2.5 we keep notification until user actually sees the message as we navigate to Conversation view only when user closes activity. Personally I like v2.5 behavior more, but I'm not sure what changed this :) I haven't debugged, but looks like when app is overlapped by any activity it's considered as visible in v2.2 and as hidden in v2.5. I suspect this change has been introduced in the scope of bug 1144132. Julien, Morpheus just want to confirm with you if the fact that we don't remove notification until user sees message is good/acceptable for v2.5? > As for "In step 6, the "back" button is not available." - sounds > interesting, wondering if it can be related to bug 1203886 - going to do a > quick check. I can only reproduce this if I tap on notification several times, so it's likely the same issue I described in bug 1203886 comment 9. Autumn.Qiu, can you reproduce "In step 6, the "back" button is not available." if you tap on notification just once? Thanks
Flags: needinfo?(qiutian)
Flags: needinfo?(mochen)
Flags: needinfo?(felash)
Flags: needinfo?(azasypkin)
See also Bug 1190613 (related to the other bugs you mentioned); that bug is 2.5+, and I proposed a System-only solution. So maybe we'll magically fix all these.
Depends on: 1190613
Flags: needinfo?(felash)
> Julien, Morpheus just want to confirm with you if the fact that we don't remove notification until user sees message is good/acceptable for v2.5? And yes, I think it's acceptable.
Hi Oleg, In step 4,I tap the reminder on the Notification tray more than once, then in step 6 the "back" button is not available. If I tap on notification just once, the "back" button can be used normally.
Flags: needinfo?(qiutian) → needinfo?(azasypkin)
That last part is bug 1203886.
Flags: needinfo?(azasypkin)
I just had a business trip last week. Sorry for my late reply. I will review the bug tomorrow, thanks for your understanding and patience.
(In reply to Autumn.Qiu from comment #6) > Hi Oleg, > In step 4,I tap the reminder on the Notification tray more than once, then > in step 6 the "back" button is not available. If I tap on notification just > once, the "back" button can be used normally. I've tested double click on notification several times after bug 1203886 landed and this issue should be addressed now.
Per talked with Steve, it seems the reason why tapping reminder on notification tray can't directly trigger Message app is because of inline activity. However, from UX perspective, it's quite weird not to trigger app immediately when tapping on reminder. IMO, the first priority is to allow user switch to the target app after tapping the reminder. Once it's done, all the bugs are also solved. So here are three proposals I have to debug: 1. Keep inline activity but make it work Using inline activity is consistent with other apps. However, user can't access to Message view until tapping Back key on message settings. So, the solution is to ask system team to create API for canceling inline activity and switching to target app when tapping the reminder on notification tray. 2. Create new window when selecting message settings Another way to fix is that selecting settings within Message app will trigger new Settings window. However, this isn't consistent with other apps. 3. Follow mechanism in v2.2 In 2.5, user might stuck on notification tray to try the reminder several times and get confused since the reminder doesn't disappear. I prefer the behavior in 2.2. User can tap the reminder and go back to Message settings page for immediate feedback. And we can apply communication apps' color to the inline activity page to imply it's still in Message app and user needs to cancel message settings to go back to message view. However, this is a workaround to this bug. I would prefer either 1 or 2. Could you help check the feasibility on engineering side and let me know which the best way is?
Flags: needinfo?(mochen)
1) is bug 1190613 that is 2.5+. 2) there is a "window" activity for settings, so we could use it. But I agree it's not consistent. 3) It would need to change some logic we have in SMS: we don't remove the notification until the window is displayed -- the information that the window is displayed/hidden, that's what changed here, not our logic. So I think it would be risky to change this now. I'd rather wait for bug 1190613 (solution 1) and see how it works then.
Could we please test this again now that bug 1190613 landed ? If it works, please dupe to bug 1190613.
Keywords: qawanted
This issue is currently reproducing in Flame 2.5 Result: Pressing the notification from the alert message or from the notification tray is still not taking the user to the MMS Environmental Variables: Device: Aries 2.5 Kk BuildID: 20151016122951 Gaia: 8999f0ba6326d815c8366e3c1155b7e4e9763b40 Gecko: ccf288f658211b6cfab33c458aaf033baed2375b Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 44.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
I believe the patch from bug 1190613 is not in this build yet. Let's try again monday.
Keywords: qawanted
Looks like it works as expected on the latest master Gaia (latest PVT still doesn't contain the change). Keeping qawanted to double confirm.
Confirmed that this issue is no longer occurring on Flame master and Aries. Following STR, user is taken to corresponding thread and subsequently the back arrow button within thread works as expected. Device: Flame 2.5 BuildID: 20151022030554 Gaia: 29ce8ec8606e59f582375234440812b046346513 Gecko: 76bd0c01d72e64ca4f261ffdb2652a91f961e930 Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 44.0a1 (2.5) Firmware Version: v18Dv4 User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Device: Aries 2.5 BuildID: 20151022105033 Gaia: 29ce8ec8606e59f582375234440812b046346513 Gecko: 76bd0c01d72e64ca4f261ffdb2652a91f961e930 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 44.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
Closing this issue as wfm. Please reopen if this begins occurring again.
Status: NEW → RESOLVED
Closed: 9 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: