[Flame][v1.4][Message]Tap new message icon, it will automatically return SMS which is just saved as draft. .And if then tap Back key, this contact will have 2 SMS items in main message view.

RESOLVED FIXED in Firefox OS v1.4

Status

Firefox OS
Gaia::SMS
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: panda67231, Assigned: steveck)

Tracking

unspecified
2.0 S4 (20june)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: bamboo[p=1])

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8429961 [details]
attachment.rar

[1.Description]:
Tap new message icon, it will automatically return SMS which is just saved as draft.  .And if then tap Back key, this contact will have 2  SMS items in main message view. 
Attach video:[20140527_113957.MP4]
Attach log:[logcat.txt&bugreport.txt]
happened time:15:35.

[2.Testing Steps]: 
Tere  is only one SMS that saved not send
1.Lanch the message app
2.Editting a SMS,then press the return  icon -->>Save as Draft
3.Press  the icon which is edit SMS
4. Press the return  icon,the contact will have 2 incons of SMS

[3.Expected Result]: 
3.It will be blank
4.The contact only have 1 incon of SMS

[4.Actual Result]: 
3.It will automatically return the UI that  the previous  SMS which saved not send 
4.The contact will have 2 incons of SMS

[5.Reproduction build]: 
Gaia        7709936aeb21859d1607dbd038489493803bb085
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/5bf038fae0f1
BuildID    20140522160202
Version    30.0
[6.Reproduction Frequency]: 2-occasionally Recurrence,5/5
The issue here is that when clicking "new message" we load the draft (step 3.), which we should not.

Saving it when pressing "back" is normal behavior then (step 4.).

I reproduce on master too, but the STR is more complicated (I believe it's the same in 1.4):

1. Launch messages app
2. open a thread
3. write some message
4. press back
5. save draft
6. open the same thread again
7. press back
8. press "new message"

=> the draft is loaded whereas it should not.
Keywords: qawanted
blocking-b2g: --- → 1.4?
We don't need QA Wanted here. This bug came from a contracting team that works with QA.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Although we might want to get that attachment in a more readable format...

Can we get a screenshot here in a picture-based format?
Keywords: qawanted
Created attachment 8430219 [details]
1.3 behavior

Able to reproduce this using steps at comment 1 on today's Buri 2.0.

I then checked today's Buri 1.3 and at step 4 of comment 1, I get the attached message, and there is no option to save draft therefore unable to go on to reproduce the bug.
Keywords: qawanted
Oops I didn't see Jason's comment.
Keywords: qawanted
Created attachment 8430246 [details]
Screenshots of bug on Buri 2.0

Attaching screenshots of bug reproducing on Buri 2.0.
Keywords: qawanted
Note that on the left screenshot of comment 6, the new thread is auto-populated with phone number and message.
triage: must fix in 2.0+ for sure. If needed in 1.4, should be able to uplift upon request
blocking-b2g: 1.4? → 2.0+
(In reply to Wesley Huang [:wesley_huang] from comment #8)
> triage: must fix in 2.0+ for sure. If needed in 1.4, should be able to
> uplift upon request

I think we need to answer a few more questions here. I'm not sure if comment 1 is the same issue as this bug also - that seems to be describing a different problem.

After I created the draft initially, when I go to edit the draft, let's say I add new content to the draft. Then, I hit the back button. How many drafts are there now? 1 or 2?
Keywords: qawanted
When you hit the back button you go back to the thread list and only one thread is created(OK), the problem (as Julien explains in comment 1) comes later if you create a new message (step 8 of Julien's STR)

In that case, in the new message we are loading the draft message (instead of an empty new one). That's the first bug, and the second one (that it's the reported in the Description of the bug) is a consequence of the first one)

Complete STR:

1. Launch messages app
2. open a thread with some messages exchanged
3. write some message
4. press back
5. save draft
6. open the same thread again
7. press back
8. press "new message"  

Result: FIRST BUG in the new message we are loading the draft message (instead of an empty new one)

9. press back
10. accept "Replace exisisting draft"

Result:two draft threads appear in the inbox for the same contact (it corresponds to the bug explaied in the description)

After testing several times I only reproduce the bugs if in step 2 I open a thread with some messages already exchanged so in step 4 when I press back button, there is no prompt with the options "Replace existing Draft" and "Discard". That's the regression and the consequence of these bugs.
Video with the complete STR described in comment 10:
https://www.youtube.com/watch?v=8WjCBVBwayk
It seem the QAWanted has been satisfied by Maria on this bug. Removing QAWanted.
Keywords: qawanted
(In reply to Wesley Huang [:wesley_huang] from comment #8)
> triage: must fix in 2.0+ for sure. If needed in 1.4, should be able to
> uplift upon request

After analyzing the video here, I don't think I'm going to agree on this one. This looks like the messages app gets out of whack with wrong behavior after a plausible set of steps could user hit. I wouldn't call this minor either - it's a broken new feature bug.

Sending this back into triage to discuss.
blocking-b2g: 2.0+ → 1.4?
(In reply to Jason Smith [:jsmith] from comment #2)
> We don't need QA Wanted here. This bug came from a contracting team that
> works with QA.

Yes, sorry, I wanted to ask to reproduce on master and ended doing it myself ;)

I also think we should fix 1.4. It's probably not a difficult fix either.
blocking-b2g: 1.4? → 1.4+
(Assignee)

Updated

4 years ago
Assignee: nobody → schung
Blocks: 1022706
Whiteboard: bamboo → bamboo[p=1]
Target Milestone: --- → 2.0 S4 (20june)
(Assignee)

Comment 15

4 years ago
Created attachment 8438210 [details] [review]
Link to github

Hi Julien, this patch clear the draft while leaving unchanged draft, and I think it should be safe enough becase we already cleared the draft in other cases(save/discard draft).
Attachment #8438210 - Flags: review?(felash)
Status: NEW → ASSIGNED
Comment on attachment 8438210 [details] [review]
Link to github

r=me
works well, small patch

Eventually bug 1010216 will remove this "draft" property but let's do it later.

Also, I think you'll need a branch-specific patch for v1.4.
Attachment #8438210 - Flags: review?(felash) → review+
(Assignee)

Comment 17

4 years ago
In master: 1508742549910ea20eb7ab247932636be942e133

For the 1.4 branch, it's only small conflicts in unit test. So I'll just push to 1.4 if no test failed in my local.

BTW, I have a question for release management team: is it necessary to uplift to 2.0(if 2.0 is also affected)?
status-b2g-v1.4: --- → affected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
Flags: needinfo?(release-mgmt)
(Assignee)

Comment 18

4 years ago
in v1.4 : b6c328d14e3c373451530b56a42b05453593fa66
status-b2g-v1.4: affected → fixed
From: https://wiki.mozilla.org/Release_Management/B2G_Landing#v2.0.0
"1.4+ blocking bugs have auto-approval to land on 2.0 if affected and do not need additional approval."

So Sheriffs should uplift it automatically to v2.0 :)
Flags: needinfo?(release-mgmt)
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
v2.0: https://github.com/mozilla-b2g/gaia/commit/7c62450e57bfdb97a344a9bb01b2c0295872f636

Yes, branch uplifts always need to go onto all affected branches. The landing rules are specifically written to cater to that.
status-b2g-v2.0: affected → fixed
You need to log in before you can comment on or make changes to this bug.