Description: If the user opens the messages share activity multiple times within the messages app, the app will appear blank and becomes unusable. Prerequisite: Have a messages thread with at least 1 message in it Repro Steps: 1) Update a Flame to 20150122010203 2) Open Messages> Thread with at least 1 message in it 3) Tap on Contact at the top of the message> Tap "View Contact" 4) Tap on the message icon within the contact details 5) Repeat step 3 and 4 Actual: The user is brought to a blank messages app with 2 non working buttons in the upper right corner Expected: The user is unable to access the same share activity multiple times within itself Environmental Variables: Device: Flame 3.0 (319mb)(Kitkat)(Full Flash) Build ID: 20150122010203 Gaia: 917b6c36717fddc6e71ffc1ec249633c8044c93c Gecko: 34e2d2bd7ec4 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Repro frequency: 10/10 100% See attached: Logcat, Video - http://youtu.be/ym8lsRFFpNU

Issue does NOT occur on Flame 2.2 The user is unable to access the messages share activity from the messages app. The icon is not visible Device: Flame 2.2 (319mb)(Kitkat)(Full Flash) BuildID: 20150122002808 Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca Gecko: 4a90da67661e Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware: V18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

NI Alive to have more insight about how this works. Derek, I'd also like more information about what you see in comment 1? Jenny, do you think we should hide some activity button in the SMS app if we're in an activity window?

Note that I also see the "blank screen" when I simply run th application sometimes. So maybe we have a graphics issue here.

The last screen on video from comment 0 looks similar to what I see when Messages-as-inline-activity doesn't receive "activity" system message due to bug 931339 (see bug 988269 comment 6)

Julien, I am unable to get my results in comment 1 to happen anymore. After 30 attempts on todays, and yesterdays Flame 2.2, this bug happened every time. Switching the tracking flag for 2.2 to affected, and 2.1 to unaffected Also this issue does NOT occur on Flame 2.1 When the user goes to the messages share activity, they are brought to a new thread (instead of an existing one) which stops the user from being able to navigate back to yet another messages share activity Environmental Variables: Device: Flame 2.1 (319Mb)(Kitkat)(Full Flash) Build ID: 20150123001230 Gaia: 234ec27050481f4787f1f4750ec26f62ce5cc2c0 Gecko: 4cdcc0e85fc0 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Requesting a window.

(In reply to Oleg Zasypkin [:azasypkin] from comment #4) > The last screen on video from comment 0 looks similar to what I see when > Messages-as-inline-activity doesn't receive "activity" system message due to > bug 931339 (see bug 988269 comment 6) The state is broken when launching the contact activity at sencond time. You can see the activity didn't enter the detail information page. It's definitely another issue here.

Is it a circular activity? Message -> Inline contact -> Inline message -> Inline contact -> Inline message? This should NOT work because the platform issue: https://bugzilla.mozilla.org/show_bug.cgi?id=931339 The second contact activity will not get the system message (as Steve said in comment 7) so it will not go into detail page.

triage: regression which breaks functionality.

Hi Wesley, just a note that the regression is because we can enter the thread view directly now and contact is viewable from clicking the header(and cause circular activity in this case). We can hide some actions like "view contact" while in activity, but it's UX call to define the proper behavior. Another option is circular activity issue in bug 931339, but we might need Alive to estimate the efforts.

(In reply to Steve Chung [:steveck] from comment #10) > Hi Wesley, just a note that the regression is because we can enter the > thread view directly now and contact is viewable from clicking the > header(and cause circular activity in this case). We can hide some actions > like "view contact" while in activity, but it's UX call to define the proper > behavior. Another option is circular activity issue in bug 931339, but we > might need Alive to estimate the efforts. I don't think there is a plan for bug 931339.. What I am curious is, what is the expected behavior of the circular activity? Why do we need to send sms to somebody and at the same time to write message while viewing the contact and at the same view the contact again while writing the message while viewing the contact while writing message? Even bug 931339 is fixed, I don't think have an infinite contact->message->contact->message loop should exist. We need UX to think about this and decide what to do.

Gaia Regression Window: Last working B2G-Inbound build: Device: Flame 2.2 BuildID: 20141208080634 Gaia: 65e97a2624638c726cce27f0b7af81952a5f312b Gecko: f9aecae09b1f Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 First broken B2G-Inbound build: Device: Flame 2.2 Build ID: 20141208095234 Gaia: bd4dcc8c4582e2368b47b0e62506d3031fb2fc09 Gecko: cfeda36af765 Gonk: Could not pull gonk. Did you shallow Flash? Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Working Gaia with Broken Gecko issue does NOT occur: Gaia: 65e97a2624638c726cce27f0b7af81952a5f312b Gecko: cfeda36af765 Working Gecko with Broken Gaia issue DOES occur: Gaia: bd4dcc8c4582e2368b47b0e62506d3031fb2fc09 Gecko: f9aecae09b1f Gaia B2G-Inbound Pushlog: https://github.com/mozilla-b2g/gaia/compare/65e97a2624638c726cce27f0b7af81952a5f312b...bd4dcc8c4582e2368b47b0e62506d3031fb2fc09 Issue appears to occur due to bug 918970 Note: The repro rate dropped in that step 5 in the str from comment 0 needed to be repeated 9 to 15 times for issue to occur in the first broken b2g-inbound build.

Augustin, can you take a look at this please? This might have been caused by the landing for bug 918970.

I'll look at it, Augustin is busy with other topics.

Sorry QA, I'd like to propose a slightly revised STR because I think bug 918970 just changed how the bug can be shown. STR: 1) Open Contacts > open a thread 2) Press the "send message" button 3) If you're in a thread, skip this step. If you're in the "new message" panel, actually send a message. => you should be in the thread now 4) Tap on Contact at the to of the message> Tap "View Contact" 5) Repeat steps 2 to 4 Can you please check this on various branches and possibly find a regression window? Thaks a lot, sorry for wasting your time.

Issue DOES occur on Flame 2.0 and 2.1 using new STR Repro rate continues to drop following new STR from comment 15. For 2.0 step 5 must be repeated up to 23 times before issue occurs. Issue severity also fluctuates from original result of nearly blank and non-functional Messages app screen, to Message app crashing to homescreen, to the phone rebooting without warning (no crash message.) A quick check reveals issue has been occurring as far back as 20140603073003 on Flame 2.0 JB base. Device: Flame 2.0 Build ID: 20150128000201 Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8 Gecko: 5bf8087572c3 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 32.0 (2.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Device: Flame 2.1 Build ID: 20150128001258 Gaia: d98bbe9d2bfdb53e80dc1ab1572bd05938a85526 Gecko: c694578ff69e Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Should really block on this then? Even if bug 918970 made it more apparent, and even if we should prevent such cycles, it looks like this issue is here since forever. Alive, do you know what the root cause is? Is it memory exhaustion that's causing the symptoms?

(In reply to Julien Wajsberg [:julienw] from comment #17) > Should really block on this then? Even if bug 918970 made it more apparent, > and even if we should prevent such cycles, it looks like this issue is here > since forever. > > Alive, do you know what the root cause is? Is it memory exhaustion that's > causing the symptoms? Two issues here: * Bug 931339: System message cannot be delivered to second iframe with the same url (gecko implementation failure because it assumed that there will not have two iframe with the same url at the same time) * If bug 931339 is fixed, we may have memory concern in this case - no idea how to nicely fix it. I wish there will be some UX improvement - for example, do not show the send message icon in second contact view activity when it knows there is already a message activity on going in the first contact activity.

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #18) > (In reply to Julien Wajsberg [:julienw] from comment #17) > > Should really block on this then? Even if bug 918970 made it more apparent, > > and even if we should prevent such cycles, it looks like this issue is here > > since forever. > > +1 to not block on this because it's really non trivial to fix.

Let's wait a bit for UX comment before making the blocking/non-blocking decision.

triage: it looks to ugly, and breaks function.

Hi Julien, To address this issue, can we do: whenever "view contact" is initiated from SMS, on the contact page, disable the message button right beside call button? So that it will always be SMS-> Contact (and ends here, no more back to SMS, user can still perform other action if needed); or Contact-> SMS-> Contact (and ends here). let me know, thanks!

(In reply to Jenny Lee from comment #22) > Hi Julien, > > To address this issue, can we do: whenever "view contact" is initiated from > SMS, on the contact page, disable the message button right beside call > button? So that it will always be SMS-> Contact (and ends here, no more back > to SMS, user can still perform other action if needed); or Contact-> SMS-> > Contact (and ends here). let me know, thanks! The problem might be the activity doesn't know who is requesting. A contact view activity doesn't know it is the message activity requesting it or some other apps - not to mention that the message activity is requested by the contact app (#1) My idea would be either don't put the message icon in the contact view activity or don't give the contact detail in the message activity. --- #1 But contact app could somewhat communicate to contact activity. So if contact app->message activity->contact activity then the contact activity could know contact app is opened.

(In reply to Jenny Lee from comment #22) > Hi Julien, > > To address this issue, can we do: whenever "view contact" is initiated from > SMS, on the contact page, disable the message button right beside call > button? So that it will always be SMS-> Contact (and ends here, no more back > to SMS, user can still perform other action if needed); or Contact-> SMS-> > Contact (and ends here). let me know, thanks! As Alive said, we don't know the activity caller. That's why I proposed removing the "view contact" and other contact-related actions from SMS when we're in an activity because I think it makes more sense to always remove these actions when in an activity than always remove the "send sms" action from Contacts when in an activity.

Just a side note, in bug 1105548 we have SharedWorker\BroadcastChannel API wrapper that allows us to know how many instances and potentially what type (activity or not) our app has. So that we can even reject second activity request with "too many activities" reason that calling app can gracefully handle :) But if Contacts-related stuff is only possible case for such issue then I'd rather go with solution in comment 24 as well.

NI Gabriele who said he might have a solution in Gecko.

Not a solution but if you start going into circular activities then we'll need to fix bug 892371 (which I'm trying to do for 2.2). Without it one random activity in the chain will be killed by the LMK once we run out of memory instead of the oldest one for example.

Thanks Alive for explaining how things work! Hi Julien, So to be clear, you are proposing whenever SMS is in activity, remove all contact related action? So for example: 1. SMS app-> View contact activity -> SMS activity (and no view contact from here, which means no context menu from tapping contact name and no entry point from more menu on top right of header)? 2. Gallery app -> share via SMS -> SMS activity - contact selected and sending (no view contact from here) 3. Contact app -> SMS activity (no view contact from here) I suppose this would be the best way to handle this issue under current structure. Harly and I were discussing the possibility of not using activity window at all, but this won't happen in near future. So if the above behavior described is correct, let's do it!

Thanks Jenny, let's do that, then :)

Taking this one since we have conclusion with UX now.

Comment on attachment 8561939 [details] [PullReq] message-avoid-viewcontact-inactivity patch Hi Julien, it's a small patch adds activity check within the option menu. You might saw empty option in the menu(when there is one view contact option originally). I've discussed with Jenny about this, and she thought we should keep the consistency first. I'm fine with either showing empty option menu or hiding menu completely, but you can still ni? her if you have different thought about this part, thanks.

Hey Jenny, I wonder if we could show the item, but in a "disabled" state? I don't know if this is something we already have globally in the system-wide styles?

Hey Julien, I don't think we have a system-wide disable state in context menu, but I don't see why not? Hey Harly! Do you think we can have a disabled button in context menu =)?

Hi Jenny, The framework team has previously decided if an item in the menu is not available, the system should not display it, which means disabled button in menu is not allowed. Hope this answer your question.

Hi Jenny, if disabled button in menu is not allowed, do you think we should display the menu with empty item(current implementation in this patch as we discussed before), or don't display the menu at all?

Hi Steve, Per discussion with Harly, we can't have disabled menu item anywhere, so can we do "don't display menu at all"? Thank you so much =)

(In reply to Jenny Lee from comment #37) > Hi Steve, > > Per discussion with Harly, we can't have disabled menu item anywhere, so can > we do "don't display menu at all"? Thank you so much =) Ok, patch updated per your request!

Comment on attachment 8561939 [details] [PullReq] message-avoid-viewcontact-inactivity patch r=me looks good to me !

Thanks! In master: https://github.com/mozilla-b2g/gaia/commit/8de3f9d45e4a295b0278f1fab0edfe059305e208

Comment on attachment 8561939 [details] [PullReq] message-avoid-viewcontact-inactivity patch [Approval Request Comment] [Bug caused by] (feature/regressing bug #): This issue existed for a long time when we apply inline activity instead of opening app in new window. [User impact] if declined: The status of activity might be wrong if user opens an activity that is as same as the originate app(circular activity issue) [Testing completed]: Yes [Risk to taking this patch] (and alternatives if risky): Low [String changes made]: N/A

v2.2: https://github.com/mozilla-b2g/gaia/commit/2ecae05c4c3fffd203f850e79cf5cfacc6f6e8f4

This issue is verified fixed on the latest Nightly Flame 3.0 and 2.2 builds. Actual Results: Message threads opened from a contact cannot bring up the contact view. Environmental Variables: Device: Flame 3.0 KK (319MB) (Full Flash) BuildID: 20150305010212 Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452 Gecko: 56492f7244a9 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Environmental Variables: Device: Flame 2.2 KK (319MB) (Full Flash) BuildID: 20150305002528 Gaia: 89af288bad6751248ff84504fa898206fee127fe Gecko: 6d8d294aa8f3 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0