Closed Bug 1016897 Opened 8 years ago Closed 8 years ago
.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 .
[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.
We don't need QA Wanted here. This bug came from a contracting team that works with QA.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Although we might want to get that attachment in a more readable format... Can we get a screenshot here in a picture-based format?
Oops I didn't see Jason's comment.
Attaching screenshots of bug reproducing on Buri 2.0.
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?
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.
It seem the QAWanted has been satisfied by Maria on this bug. Removing 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.
Whiteboard: bamboo → bamboo[p=1]
Target Milestone: --- → 2.0 S4 (20june)
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)
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+
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)?
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 :)
Status: ASSIGNED → RESOLVED
Closed: 8 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.
You need to log in before you can comment on or make changes to this bug.