on 2.1 build from yesterday. STR: Receive 2 SMS with pre-paid card so you get the notification about the amount left on your SIM card. Discard both overlays by clicking OK. Back button in SMS app doesn't work any more

QAwanted for branch check.

Unable to reproduce this issue in latest Flame 2.1, 2.2 builds (Full Flash, nightly, 319 MB memory). Notifications for the pre-paid SIM card did not trigger after receiving SMS and MMS type messages over a data connection. Repro attempts: 0/10 Environmental Variables: Device: Flame 2.1 Build ID: 20141028001203 Gaia: a0174f7166745256aaca1cb3aa9f894033fbffa6 Gecko: 43bda3541f6b Version: 34.0 (2.1) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.2 BuildID: 20141028040202 Gaia: 6a7fb482a03c5083ef79b41e7b0dfab27527cd04 Gecko: a255a234946e Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89 Version: 36.0a1 (2.2) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Hey Gregor, just want to check with you here: "Discard both overlays by clicking OK.". Which overlay is this? Was there "class0" SMS (means they show up in an alert box) ?

(In reply to Julien Wajsberg [:julienw] from comment #3) > Hey Gregor, > > just want to check with you here: "Discard both overlays by clicking OK.". > Which overlay is this? Was there "class0" SMS (means they show up in an > alert box) ? The one I get for a pre-paid sim card that shows the amount thats left on the card after sending a sms.

NI Gregor to know whether this happens with the app initially closed, launched, or both.

I just tested after a new OTA update. It doesn't matter if the app is launched or not. It reproduces for example when the app is not launched and the phone is just sitting idle with the screen off.

[Blocking Requested - why for this release]: SMS app stops working when I receive/send 2 sms with sms0 alerts in between. I have to kill/restart the sms app in order to see the messages I receive for example.

We are unable to attempt to repro this bug due to the fact that our prepaid SIMs do not send amount left notifications when we send or receive SMSes.

I have the feeling that could be a USSD message from the network. Not handled by sms or dialer. I have one sim that will send me this message each time i send a sms or I made a call. Will try with my sim to double check what Gregor comments.

Francisco, this is breaking the SMS app, so I think this is happening in the SMS app :)

(In reply to Julien Wajsberg [:julienw] from comment #10) > Francisco, this is breaking the SMS app, so I think this is happening in the > SMS app :) Thanks Julien, definitely what I commented is not the sms 0.

Triage: Major issue on SMS seriously affecting a Dual prepaid SIM users.

I can reproduce the issue with small hack in SMS code that considers every message as class-0 one. ni? myself to look closer.

Hey Alexandre and Alive, We have some weird behaviour related to alerts inside navigator.mozApps.getSelf().success callback. I'm not sure whether it's related to Gecko or more to Gaia modal window management, so ni? you both :) Basically SMS app listens for system message ('sms-received' in our case) and should display special alert for every such message, so, if simplify, we have something like this (more here [1]): navigator.mozApps.getSelf().onsuccess = () => alert('Alert'); In this bug user receives two such messages, one right after another, so that user didn't dismiss first alert before second alert is called. Once user dismisses both alerts one by one, we're observing very weird behaviour: any "setTimeout" callback is never executed anymore that actually breaks a lot of stuff. Could you please help with that? As as side note: if we wrap alert in setTimeout(..., 0) inside getSelf().onsuccess callback - everything works fine. Thanks! [1] https://github.com/mozilla-b2g/gaia/blob/5c22ab657bf06664ca084c12d86343e12f309c00/apps/sms/js/activity_handler.js#L351

(In reply to Oleg Zasypkin [:azasypkin] from comment #14) > Hey Alexandre and Alive, > > We have some weird behaviour related to alerts inside > navigator.mozApps.getSelf().success callback. I'm not sure whether it's > related to Gecko or more to Gaia modal window management, so ni? you both :) Are you sure you ni? the proper people ? I'm not sure I have anything to do with this :( > > Basically SMS app listens for system message ('sms-received' in our case) > and should display special alert for every such message, so, if simplify, we > have something like this (more here [1]): > > navigator.mozApps.getSelf().onsuccess = () => alert('Alert'); > > In this bug user receives two such messages, one right after another, so > that user didn't dismiss first alert before second alert is called. Once > user dismisses both alerts one by one, we're observing very weird behaviour: > any "setTimeout" callback is never executed anymore that actually breaks a > lot of stuff. Can you clarify what you are naming "alert" ? Is this a notification as in "object from the Notification API" ? > > Could you please help with that? > > As as side note: if we wrap alert in setTimeout(..., 0) inside > getSelf().onsuccess callback - everything works fine. > > Thanks! > > [1] > https://github.com/mozilla-b2g/gaia/blob/ > 5c22ab657bf06664ca084c12d86343e12f309c00/apps/sms/js/activity_handler.js#L351

If we could make sure this[1] is called for both alert, we could make sure this is a platform issue. https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_modal_dialog.js#L378

It's more like a platform issue, ping Kanru.

Just one more thing, not sure if it's useful or not, if we execute the following code snippet anywhere in our code, we'll observe the same effect as mentioned in comment 15: navigator.mozApps.getSelf().onsuccess = () => { console.log('1st alert begin'); alert(1); console.log('1st alert end'); }; navigator.mozApps.getSelf().onsuccess = () => { console.log('2nd alert begin'); alert(2); console.log('2nd alert end'); }; The log output is like: 1st alert begin 2nd alert begin When user dismisses both alerts, log output is the following: 2nd alert end

In the meantime let's get rid of window.alert in favour of shared\custom_dialog.js as Gecko issue can take some time to resolve.

So the log I get from above script is I/Gecko (19119): BrowserElementChild - _waitForResult([object XrayWrapper [object Window]]) I/Gecko (19119): BrowserElementChild - Entering modal state (outerWindowID=1, innerWindowID=4) I/Gecko (19119): BrowserElementChild - Nested event loop - begin I/Gecko ( 8526): BrowserElementParent.jsm - handleShowPrompt {"promptType":"alert","title":"The page at app://clock.gaiamobile.org says:","message":"1","windowID":{"outer":1,"inner":4},"msg_name":"showmodalprompt"} I/Gecko ( 8526): BrowserElementParent.jsm - Event will have detail: {"promptType":"alert","title":"The page at app://clock.gaiamobile.org says:","message":"1","msg_name":"showmodalprompt"} I/Gecko (19119): BrowserElementChild - _waitForResult([object XrayWrapper [object Window]]) I/Gecko (19119): BrowserElementChild - Entering modal state (outerWindowID=1, innerWindowID=4) I/Gecko (19119): BrowserElementChild - Nested event loop - begin E/GeckoConsole(19119): Content JS LOG at Scratchpad/1:11 in anonymous: 1st alert begin E/GeckoConsole(19119): Content JS LOG at Scratchpad/1:16 in anonymous: 2nd alert begin I/Gecko ( 8526): BrowserElementParent.jsm - handleShowPrompt {"promptType":"alert","title":"The page at app://clock.gaiamobile.org says:","message":"2","windowID":{"outer":1,"inner":4},"msg_name":"showmodalprompt"} I/Gecko ( 8526): BrowserElementParent.jsm - Event will have detail: {"promptType":"alert","title":"The page at app://clock.gaiamobile.org says:","message":"2","msg_name":"showmodalprompt"} D/wpa_supplicant(16524): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c D/wpa_supplicant(16524): wlan0: Control interface command 'SIGNAL_POLL' D/wpa_supplicant(16524): nl80211: survey data missing! I/Gecko (19119): BrowserElementChild - recvStopWaiting(outer=1, inner=4, returnValue=undefined) I/Gecko (19119): BrowserElementChild - recvStopWaiting [object XrayWrapper [object Window]] I/Gecko (19119): BrowserElementChild - Nested event loop - finish I/Gecko (19119): BrowserElementChild - Leaving modal state (outerID=1, innerID=4) E/GeckoConsole(19119): Content JS LOG at Scratchpad/1:18 in anonymous: 2nd alert end I/Gecko (19119): BrowserElementChild - recvStopWaiting(outer=1, inner=4, returnValue=undefined) I/Gecko (19119): BrowserElementChild - recvStopWaiting: No record of outer window ID 1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We delete the window record too early so we stuck in the nested event loop. Actually these codes are supposed to handle exactly the case above.. I think I know how to fix it.

Filed bug 1094083

Hey Kan-Ru, Thanks for your help! Do you know how complex and risky the fix for bug 1094083 can be and will it be possible to uplift it to v2.0 (probably v2.0m), v2.1 in timely fashion? I'm just wondering whether we need to proceed with gaia-only fix that replaces window.alert usage with CustomDialog or just wait for the fix in bug 1094083. Thanks!

(In reply to Oleg Zasypkin [:azasypkin] from comment #22) > Hey Kan-Ru, > > Thanks for your help! > > Do you know how complex and risky the fix for bug 1094083 can be and will it > be possible to uplift it to v2.0 (probably v2.0m), v2.1 in timely fashion? > > I'm just wondering whether we need to proceed with gaia-only fix that > replaces window.alert usage with CustomDialog or just wait for the fix in > bug 1094083. I have no opinion whether window.alert or CustomDialog is better. The fix for bug 1094083 should be ready in one or two days and we will definitely want to uplift it to stable branches, but that would require approval from release managers. (I guess it warrants a 2.1+ since it blocks this bug?)

(In reply to Kan-Ru Chen [:kanru] from comment #23) > (In reply to Oleg Zasypkin [:azasypkin] from comment #22) > > Hey Kan-Ru, > > > > Thanks for your help! > > > > Do you know how complex and risky the fix for bug 1094083 can be and will it > > be possible to uplift it to v2.0 (probably v2.0m), v2.1 in timely fashion? > > > > I'm just wondering whether we need to proceed with gaia-only fix that > > replaces window.alert usage with CustomDialog or just wait for the fix in > > bug 1094083. > > I have no opinion whether window.alert or CustomDialog is better. The fix > for bug 1094083 should be ready in one or two days and we will definitely > want to uplift it to stable branches, but that would require approval from > release managers. Thanks Kan-Ru! That's sounds good to me, so let's wait for the fix for bug 1094083 then. We have wip "CustomDialog" patch anyway in case something goes wrong :) > (I guess it warrants a 2.1+ since it blocks this bug?) Yeah, I think so

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #12) > Triage: Major issue on SMS seriously affecting a Dual prepaid SIM users. Hi Johan, Do you have SIM suitable for verifying this case?

(In reply to Eric Chang [:ericcc] [:echang] from comment #25) > Hi Johan, Do you have SIM suitable for verifying this case? Sorry, I don't have any prepaid SIM cards for now. I'll ask IT if I can get some.

Note: this specific issue is happening with some carriers only. However, the "alert" issue could happen anywhere in the web.

Comment 14 fulfilled branch checking request. And as comment 8 stated, we don't have a SIM that could repro this bug so we can't assist this bug further. Removing tag.

NI Gregor, bug 1094083 landed, can you check with a build that contains that fix?

see previous comment

(In reply to Julien Wajsberg [:julienw] from comment #29) > NI Gregor, bug 1094083 landed, can you check with a build that contains that > fix? I will test once it hits 2.1 and I get it with the OTA. Ping me if I forget.

Duping. Gregor you should get the bugmail once it lands :)

Just wanted to confirm that all test cases I mentioned are working fine now on the latest master PVT build.

WFM \o/

This is partner blocker per bug 1105129. Nominate to 2.0M+