Closed Bug 1076703 Opened 5 years ago Closed 5 years ago

[woodduck] There is no response in switch data connection page while pressing OK button.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 unaffected, b2g-v2.2 unaffected)

RESOLVED FIXED
2.1 S7 (24Oct)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.0M --- verified
b2g-v2.1 --- unaffected
b2g-v2.2 --- unaffected

People

(Reporter: jj.evelyn, Assigned: julienw)

References

Details

(Whiteboard: [2.0-woodduck-test-run-1][sms-sprint-2.1S6])

Attachments

(4 files, 2 obsolete files)

+++ 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+.
blocking-b2g: --- → 2.0+
Duplicate of this bug: 1060921
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?
Flags: needinfo?(ehung)
Hubert, I'm confused with the steps here. Can you please upload a video with all steps on a Flame?

Thanks a lot!
Flags: needinfo?(hlu)
Attached video video (obsolete) —
Flags: needinfo?(hlu)
Attached file logcat (obsolete) —
Sorry Hubert, I'd need a video especially for steps 4 to 6. Thanks !
Flags: needinfo?(hlu)
Attached video video
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.
Attachment #8501667 - Attachment is obsolete: true
Attachment #8501670 - Attachment is obsolete: true
Flags: needinfo?(hlu)
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 :/
Blocks: 983315
Actually, taking it now.
Assignee: nobody → felash
Status: NEW → ASSIGNED
Flags: needinfo?(ehung)
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.
Keywords: qawanted
Attached file 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.
Attachment #8502500 - Flags: review?(azasypkin)
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment on attachment 8502500 [details] [review]
github PR v2.0

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Created attachment 8502500 [details] [review]
> 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.
Attachment #8502500 - Flags: review?(azasypkin) → review+
Whiteboard: [2.0-woodduck-test-run-1] → [2.0-woodduck-test-run-1][sms-sprint-2.1S6]
Comment on attachment 8502500 [details] [review]
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
Attachment #8502500 - Flags: approval-gaia-v2.0?
Attachment #8502500 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0?(bbajaj)
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!
blocking-b2g: 2.0+ → 2.0M+
Hey Bhavana, can you please look at the approval request here? I think it's a quite important bug... Thanks!
Flags: needinfo?(bbajaj)
BLocking on 2.0 as this is reproducible on Flame and approving the patch.
blocking-b2g: 2.0M+ → 2.0+
Flags: needinfo?(bbajaj)
Attachment #8502500 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
v2.0: b7d09946b306b700125ab2bee29eb44ff633c9f2
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S7 (24Oct)
QA Contact: croesch
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
Attached video vidoe
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/11615/
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.