Closed Bug 1178712 Opened 5 years ago Closed 5 years ago
[Message]When we launch Message from a contact details view for the second time, device does not enter the compose view, but enters a view where there is only a title "message".
[1.Description]: [Flame v2.2&v3.0][Nexus5 v2.2&v3.0][Message]When we launch message from a contact details view for the second time, the message will not enter the compose view, but enter s a view where there is only a title "message" with a null screen below. See attachments: VIDEO0598.3gp & logcat.txt Found at: 18:58 [2.Testing Steps]: 1. Launch Contact 2. Tap one contact(the contact contains phone number and it has a message thread); 3. Tap "Message" button 4. Tap "Call" button on the title bar. 5. Switch to Contact view by tapping button at middle bottom. 6. Tap the same contact again and tap message button. [3.Expected Result]: 6. Can enter the compose view. 6. Can't enter the compose view, and it stays at a view where there is a title "Message" with a null screen below. [5.Reproduction build]: Flame 2.2 version(Affected): Build ID 20150628002505 Gaia Revision 0179935627012dfde3ca036c9a71035be463b7ad Gaia Date 2015-06-26 21:13:44 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/35e09270da3a Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150628.035537 Firmware Date Sun Jun 28 03:55:48 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 version(Affected): Build ID 20150629134017 Gaia Revision 27fe0f4261e3685187769411f2f74cff19287b19 Gaia Date 2015-06-29 14:29:00 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/c26dbd63604d Gecko Version 42.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150629.170951 Firmware Date Mon Jun 29 17:10:03 EDT 2015 Bootloader L1TC000118D0 N5 2.2 version (Affected): Build ID 20150629162503 Gaia Revision b39d4f5b4937592ded19ec65e113a74177ae1f86 Gaia Date 2015-06-29 13:01:35 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cefa70ef71e4 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150629.223845 Firmware Date Mon Jun 29 22:39:02 EDT 2015 Bootloader HHZ12f N5 3.0 version (Affected): Build ID 20150629134017 Gaia Revision 27fe0f4261e3685187769411f2f74cff19287b19 Gaia Date 2015-06-29 14:29:00 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/c26dbd63604d Gecko Version 42.0a1 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150629.170843 Firmware Date Mon Jun 29 17:09:00 EDT 2015 Bootloader HHZ12f [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test
Given we disable "contacts" activities when we are in an activity already, should we also disable the "call" activity ?
Whiteboard: [v2.2-nexus-5-l] → [v2.2-nexus-5-l][sms-papercuts]
After quick investigation, it seems the issue is the following: 1. Contacts runs Messages app instance#1 as inline activity; 2. Then when user taps on Call button he's forwarded to Dialer (window activity); 3. Then in Dialer, user goes into Contacts tab and runs Messages app instance#2 as inline activity; The issue is that second activity request system message is received by instance#1 and not by instance#2. Instance#2 is run and waiting for activity request system message, but it has already been consumed by instance#1. So we either can unsubscribe from activity request system message in instance#1 once it's consumed, or Gecko should be smarter and if it runs new app instance as inline activity it should pass activity request system message only to that instance. Honestly I expected that instance#1 will be killed before instance#2 is created as it's done currently for other similar cases (you can follow STR from comment 0, but on step 4 just swipe to dialer instead of tap on Call button) :) Is it preserved because of the fact that it originated Dialer window activity request? Hey Etienee, not sure it's question for you, but at what level you think it should be fixed? Thanks!
Ahah. Nice one. And nice investigation! The piece that is unclear to me is: how come #inline1 steals from #inline2 but the app instance itself doesn't steal from #inline1? Do you have logic in the sms app for this? (conditionally setting the message handler) If yes, I'd add support for the "auto unregister" there. Because, since activities are mozChromeEvent, based I don't see how gecko could find the "correct" window by itself :/
(In reply to Etienne Segonzac (:etienne) from comment #4) > Ahah. Nice one. And nice investigation! > The piece that is unclear to me is: how come #inline1 steals from #inline2 > but the app instance itself doesn't steal from #inline1? > > Do you have logic in the sms app for this? (conditionally setting the > message handler) Yeah, on master we don't register activity system message handler if we don't have such pending message (via mozHasPendingMessage), but, hmmm, on v2.2 we always do this - I'll try to find out why main instance doesn't receive activity request system message there. Just a silly guess: can Gecko somehow send message only to windows that are in "inline-activity mode"?
(In reply to Oleg Zasypkin [:azasypkin] from comment #5) > (In reply to Etienne Segonzac (:etienne) from comment #4) > > Ahah. Nice one. And nice investigation! > > The piece that is unclear to me is: how come #inline1 steals from #inline2 > > but the app instance itself doesn't steal from #inline1? > > > > Do you have logic in the sms app for this? (conditionally setting the > > message handler) > > Yeah, on master we don't register activity system message handler if we > don't have such pending message (via mozHasPendingMessage), but, hmmm, on > v2.2 we always do this - I'll try to find out why main instance doesn't > receive activity request system message there. Just a silly guess: can Gecko > somehow send message only to windows that are in "inline-activity mode"? AFAIK only the system app knows that. And, currently, after the activity picker choice (when you need to choose), gecko doesn't get anything back from the system app. (We could pretty easily dispatch a mozContentEvent from the sytem app pointing to the correct iframe, but there might be much more work on the gecko side.)
Hi Gregor, Could you help to find someone who can help from system front end? Thanks!
blocking-b2g: --- → 2.5+
As a workaround we can also do comment 2. Honestly I don't think anybody will fix system messages now, this is too risky.
I realize we could also just do bug 1032273: when calling telephony.dial directly we woud not launch the Dialer app and would not fall into this bug. 2 birds with the same stone !
We can also use workaround from comment 3 i.e. "unsubscribe from activity request system message in instance#1 once it's consumed" :)
(In reply to Josh Cheng [:josh] from comment #7) > Hi Gregor, > Could you help to find someone who can help from system front end? > Thanks! Why is this a blocker?
Flags: needinfo?(anygregor) → needinfo?(jocheng)
[Blocking Requested - why for this release]: Hi Gregor, The bug basically causes Message app fail to perform as it should be and lead user nowhere. Given there fix could be risky per comment from Julien and this could be somewhat tricky to reproduce. I agree to postpone the fix and unblock 2.5.
blocking-b2g: 2.5+ → 2.5?
Flags: needinfo?(jocheng) → needinfo?(anygregor)
We will be removing the contacts tab from the dialer, but I suggest that we still look at this, since we can have other combinations of activities that will reproduce the same error.
Component: Gaia::SMS → Gaia::System::Window Mgmt
Not blocking since its not a regression. Lets see if Etienne can pick it up in the 2.5 time frame.
I think we have a dupe in the SMS app for this but can't find it.
Component: Gaia::System::Window Mgmt → Gaia::SMS
No I don't think we have a dupe for this specific issue. Bug 818000 could be related though, as system messages are not working well as soon as we have several instances. For example see . But bug 818000 is more about the fact that we don't receive messages at all in some situations. I think there is work both for Gecko and Gaia here, as you suggest in comment 6. And I think what you suggest in comment 6 is the right solution: Gecko needs to know which iframe the System app just launched, so that it can redirect system messages to that window. Maybe there is another way to do that: I'm thinking that Gecko could wait for the next iframe to show up before sending a message to that iframe. I don't know how easy it is though. Sean, I've seen you did some patch around system messages lately, maybe you'd like to take this one?  https://dxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageManager.js?offset=300#272-281
That said, it's really not an urgent bug in my opinion. So Sean if you have more important work to do, it's really fine !
Well, I might try to help with the issue with my remaining bandwidth only when it's available sometimes, just like the patch made lately. So I'd like to put it as a low priority item in my backlog. And it's also alright if someone would like to take it in the future. Btw, actually it looks a duplicate of bug 931339 to me. The suggestion in comment 6 looks a viable solution IMO. On the other hand, for the one mentioned in comment 17, I'm afraid it would need higher overhead to make Gecko system messages monitor newly showing up iframes. Besides, I'm afraid the correct target sometimes might not be shown up as the next one, if another iframe happens to be opened just right before the target one (maybe in some 2nd-screen scenarios, but not quite sure if there's really a timing issue).
Yeah, you're right, it definitely looks like bug 931339, I'm duping.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 931339
BTW this shows how well our tracking system works: that bug had tracking-b2g:+ for 7 months already.
You need to log in before you can comment on or make changes to this bug.