Closed
Bug 1076703
Opened 10 years ago
Closed 10 years ago
[woodduck] There is no response in switch data connection page while pressing OK button.
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 unaffected, b2g-v2.2 unaffected)
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
Reporter | ||
Comment 1•10 years ago
|
||
Generic bug of bug 1060921 which is 2.0M+.
blocking-b2g: --- → 2.0+
Assignee | ||
Comment 3•10 years ago
|
||
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)
Assignee | ||
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
Flags: needinfo?(hlu)
Comment 6•10 years ago
|
||
Assignee | ||
Comment 7•10 years ago
|
||
Sorry Hubert, I'd need a video especially for steps 4 to 6. Thanks !
Flags: needinfo?(hlu)
Comment 8•10 years ago
|
||
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)
Comment 9•10 years ago
|
||
Assignee | ||
Comment 10•10 years ago
|
||
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?
Assignee | ||
Comment 11•10 years ago
|
||
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
Assignee | ||
Comment 12•10 years ago
|
||
Actually, taking it now.
Assignee: nobody → felash
Status: NEW → ASSIGNED
Flags: needinfo?(ehung)
Assignee | ||
Comment 13•10 years ago
|
||
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
Assignee | ||
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
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?]
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 16•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Whiteboard: [2.0-woodduck-test-run-1] → [2.0-woodduck-test-run-1][sms-sprint-2.1S6]
Assignee | ||
Comment 17•10 years ago
|
||
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?
Updated•10 years ago
|
status-b2g-v2.0M:
--- → affected
Assignee | ||
Updated•10 years ago
|
Attachment #8502500 -
Flags: approval-gaia-v2.0? → approval-gaia-v2.0?(bbajaj)
Comment 18•10 years ago
|
||
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+
Comment 19•10 years ago
|
||
Landed in v2.0m per request.
https://github.com/mozilla-b2g/gaia/commit/f93f620cdb677cbb9e189e02b2bc647fa73c74d4
Assignee | ||
Comment 20•10 years ago
|
||
Hey Bhavana, can you please look at the approval request here? I think it's a quite important bug... Thanks!
Flags: needinfo?(bbajaj)
Comment 21•10 years ago
|
||
BLocking on 2.0 as this is reproducible on Flame and approving the patch.
blocking-b2g: 2.0M+ → 2.0+
Flags: needinfo?(bbajaj)
Updated•10 years ago
|
Attachment #8502500 -
Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Assignee | ||
Comment 22•10 years ago
|
||
v2.0: b7d09946b306b700125ab2bee29eb44ff633c9f2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Target Milestone: --- → 2.1 S7 (24Oct)
Updated•10 years ago
|
QA Contact: croesch
Comment 23•10 years ago
|
||
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
Comment 24•10 years ago
|
||
Comment 25•9 years ago
|
||
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.
Description
•