1016897 - [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.

Status: RESOLVED FIXED

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

Description

[panda67231]

Attachment: 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

Comment 1

[Julien Wajsberg [:julienw]]

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.

Comment 2

[Jason Smith [:jsmith]]

We don't need QA Wanted here. This bug came from a contracting team that works with QA.

Comment 3

[Jason Smith [:jsmith]]

Although we might want to get that attachment in a more readable format...

Can we get a screenshot here in a picture-based format?

Comment 4

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: 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.

Comment 5

[Pi Wei Cheng [:piwei] (inactive)]

Oops I didn't see Jason's comment.

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: Screenshots of bug on Buri 2.0

Attaching screenshots of bug reproducing on Buri 2.0.

Comment 7

[Pi Wei Cheng [:piwei] (inactive)]

Note that on the left screenshot of comment 6, the new thread is auto-populated with phone number and message.

Comment 8

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: must fix in 2.0+ for sure. If needed in 1.4, should be able to uplift upon request

Comment 9

[Jason Smith [:jsmith]]

(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?

Comment 10

[Maria Angeles Oteo (:oteo)]

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.

Comment 11

[Maria Angeles Oteo (:oteo)]

Video with the complete STR described in comment 10:
https://www.youtube.com/watch?v=8WjCBVBwayk

Comment 12

[Cody Roesch [:croesch]]

It seem the QAWanted has been satisfied by Maria on this bug. Removing QAWanted.

Comment 13

[Jason Smith [:jsmith]]

(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.

Comment 14

[Julien Wajsberg [:julienw]]

(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.

Comment 15

[Steve Chung [:steveck]]

Attachment: 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).

Comment 16

[Julien Wajsberg [:julienw]]

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.

Comment 17

[Steve Chung [:steveck]]

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)?

Comment 18

[Steve Chung [:steveck]]

in v1.4 : b6c328d14e3c373451530b56a42b05453593fa66

Comment 19

[Julien Wajsberg [:julienw]]

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 :)

Comment 20

[Ryan VanderMeulen [:RyanVM]]

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.