+++ This bug was initially created as a clone of Bug #1060921 +++ Description: There is no response in switch data connection page while pressing OK button. Repro Steps: 1. Insert 2 SIM cards. 2. Go to Settings/SIM Manager 3. The setting of Data is "SIM 1" 4. Launch Messages to compose a MMS, and send it to SIM1. 5. Long press "Send" button, then select "SIM2". 6. Press OK in switch data connection warning page. Actual: There is no response in switch data connection page while pressing OK button. Expected: Data connection should be switched and page will be back to message page. Environment: Gaia ee5cf3aff7e66ec5e899bdffa27ef51bfa40f0f0 Gecko bcee32cba2a203eb23dab3747d238579bcb723f4 BuildID 20140828102944 Version 32.0 ro.build.version.incremental=1409192296 ro.build.date=Thu Aug 28 10:18:26 CST 2014

Generic bug of bug 1060921 which is 2.0M+.

Evelyn, may I please access the duped bug? Also, what happens between steps 4 and 5? Do we need to write another MMS? Is the issue happening while the first MMS is sent?

Hubert, I'm confused with the steps here. Can you please upload a video with all steps on a Flame? Thanks a lot!

Sorry Hubert, I'd need a video especially for steps 4 to 6. Thanks !

Oops! My fault. I attach wrong video and logcat. The correct logcat and video are attaced and incorrect files are removed. == Mapping of Video and Steps on comment 0 == 00:00 ~ 00:05 => Step 4 00:06 ~ 00:09 => Step 5 00:10 ~ 00:24 => Step 6 00:25 ~ END => User should close switch data connection page, and try to switch data connection again.

Hubert, from your Video, I see that the step 4 is incorrect then: we don't send the MMS through SIM 1 at all. Here is a corrected STR: 1. Insert 2 SIM cards. 2. Go to Settings/SIM Manager 3. The setting for Data and SMS is "SIM 1" 4. Launch Messages, press "new message", compose a MMS 5. Long press "Send" button, then select "SIM2". 6. Press OK in switch data connection warning page. => nothing happens What's important is that we need to be in the "new message" panel. But thanks, I think we have a real and important bug here, let's handle it! Is it ok if we wait for next week's sprint to handle this?

What disturbs me the most here is that we probably had this issue in v2.0 for a very long time (bug 983315) and it was not caught by any QA until now :/

Actually, taking it now.

I think it's been fixed in master and v2.1 by bug 1041765. Asking QA to check it. So the bug would happen in v2.0 only.

Hey Oleg, here is a quick fix for this issue. There is a small glitch left, but I think this would need a quite big rewrite on how resending works to make it work properly: 1. set Data to SIM 2, SMS to SIM 1 2. in Messages, send a MMS to someone (for example, add a subject). It does not matter if you start in "new message" panel or "thread" panel 3. accept the switch => the thread for the user is displayed, the message has the "sending" state => after some seconds (when the switch is done), we actually resend the message. Before we actually resend, we remove the message node that we just resent. => It's only when we get the "sending" message that we add it again Between the moment we remove the previous node and the moment we add the new node, some time pass, and there is a very visible glitch. A solution would be to keep the message id for the message we resend, and remove the message DOM only when we get the "sending" event. But this is more work that I'd like to do for a v2.0+ bug. Please tell me your thoughts. We can file a separate bug for this specific issue.

Using STR from Comment 10: The bug is indeed FIXED in 2.2 and 2.1 KK branches. Tested with Shallow Flash on 319mb using Engineering builds This bug repro's on Flame KK builds: Flame 2.0 KK, Flame 2.0 KK Base Actual Results: The OK button has no functionality when trying to switch to SIM 2 when sending an MMS. Repro Rate: 2/2 Environmental Variables: Device: Flame 2.0 KK BuildID: 20141008192303 Gaia: c1f60895e5bcc6a951f3667c2a1e1bd39d393420 Gecko: 4540201b5da0 Version: 32.0 (2.0) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.0 Base KK BuildID: 20140904160718 Gaia: 506da297098326c671523707caae6eaba7e718da Gecko: Gonk: Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ----------------------------------------------------------------- ----------------------------------------------------------------- This bug does NOT repro on Flame kk build: Flame 2.2 KK, Flame 2.1 KK Actual Result: The ok button works correctly when switching SIM to send the MMS. Repro Rate: 0/4 Environmental Variables: Device: Flame Master KK BuildID: 20141008170004 Gaia: 7b92615bdc97e5c675cd385ec68bc5e47e0c5288 Gecko: f0bb13ef0ee4 Version: 35.0a1 (Master) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.1 KK BuildID: 20141008192207 Gaia: 7e2ef41d3ac98757acaf490b5413fb42061ad3e6 Gecko: 75ebb70f8b38 Version: 34.0a2 Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment on attachment 8502500 [details] github PR v2.0 (In reply to Julien Wajsberg [:julienw] from comment #14) > Created attachment 8502500 [details] > github PR v2.0 > > Hey Oleg, > > here is a quick fix for this issue. > > There is a small glitch left, but I think this would need a quite big > rewrite on how resending works to make it work properly: > > 1. set Data to SIM 2, SMS to SIM 1 > 2. in Messages, send a MMS to someone (for example, add a subject). It does > not matter if you start in "new message" panel or "thread" panel > 3. accept the switch > => the thread for the user is displayed, the message has the "sending" state > => after some seconds (when the switch is done), we actually resend the > message. Before we actually resend, we remove the message node that we just > resent. > => It's only when we get the "sending" message that we add it again > > Between the moment we remove the previous node and the moment we add the new > node, some time pass, and there is a very visible glitch. > > A solution would be to keep the message id for the message we resend, and > remove the message DOM only when we get the "sending" event. But this is > more work that I'd like to do for a v2.0+ bug. > > Please tell me your thoughts. We can file a separate bug for this specific > issue. Sounds good to me and it's the safest patch for v2.0 I can think of. Let's file a separate bug for the issue you're describing.

Comment on attachment 8502500 [details] github PR v2.0 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Bug 983315 [User impact] if declined: user can't switch the SIM used for data when trying to send a MMS in some common situation [Testing completed]: yes, both manually and unit tests [Risk to taking this patch] (and alternatives if risky): low [String changes made]: none

This is reported by partner for 2.0M, make it 2.0M+. Hi Bhavana, Please decide whether this is important enough to land on 2.0, thanks!

Landed in v2.0m per request. https://github.com/mozilla-b2g/gaia/commit/f93f620cdb677cbb9e189e02b2bc647fa73c74d4

Hey Bhavana, can you please look at the approval request here? I think it's a quite important bug... Thanks!

BLocking on 2.0 as this is reproducible on Flame and approving the patch.

v2.0: b7d09946b306b700125ab2bee29eb44ff633c9f2

This issue can't repro on woodduck 2.0 and Flame 2.0. See attachment: Verify_video.MP4 Reproducing rate: 0/3 Woodduck 2.0 buid: Gaia-Rev ee5cf148b4c546beea9bfb799d2a3ee62074957d Gecko-Rev 73601b71861cbc2f180c4d2653cec3e9fbb39db5 Build-ID 20141114050313 Version 32.0 Flame 2.0 versions: Gaia-Rev ab83632c92f9fc571b11d8468b6901cc4ed905c0 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e21bf45e6c44 Build-ID 20141113000201 Version 32.0

Test case has been added in moztrap: https://moztrap.mozilla.org/manage/case/11615/