Closed Bug 1092112 Opened 5 years ago Closed 5 years ago

[Messages] Waiting screen never disappears if user confirms thread deletion when there isn't any selected thread

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

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

RESOLVED FIXED
2.1 S8 (7Nov)
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- wontfix
b2g-v2.0M --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- unaffected

People

(Reporter: azasypkin, Assigned: azasypkin)

References

Details

(Whiteboard: [sms-sprint-2.1S8])

Attachments

(3 files)

STR:

* Open thread list (inbox) panel and enter edit mode;
* Select _single_ thread, tap on "Delete" header button, but don't confirm deletion yet;
* Receive message to the selected thread and only then confirm deletion.

Expected result: user should be returned to the thread list panel in default(non-edit) mode and target thread should _not_ be deleted. This happens because newly received message unchecks target thread (in fact thread node is recreated).

Actual result: waiting screen never disappears and user should kill Messages app via Task manager to return app in normal state.

In this bug we just want solution according to the expected result above. 

We can also be smarter and keep selection once we receive new message and in this case we should remove only _old_ (that existed before confirmation screen was presented to the user) thread messages. But this is separate feature request that requires some more work.
Duplicate of this bug: 1087991
Hey Steve,

Could you please review patch that should fix this issue for v2.1 and v2.0?

Thanks!
Attachment #8514918 - Flags: review?(schung)
blocking-b2g: --- → 2.0M?
blocking-b2g: 2.0M? → 2.0M+
Hi Steve,
This is request by partner urgently. Could you please help to review the patch in your earliest possible? Thank you very much!
Flags: needinfo?(schung)
Comment on attachment 8514918 [details] [review]
GitHub pull request URL (v2.1)

Nice and quick fix, thanks!
Flags: needinfo?(schung)
Attachment #8514918 - Flags: review?(schung) → review+
(In reply to Steve Chung [:steveck] from comment #4)
> Comment on attachment 8514918 [details] [review]
> GitHub pull request URL (v2.1)
> 
> Nice and quick fix, thanks!

Thanks for review! 

Note to sheriffs: only for v2.1, v2.0 and v2.0m branches, master doesn't need this fix

Thanks!
Keywords: checkin-needed
This needs Gaia v2.1 approval before it can land on 2.1.
Flags: needinfo?(azasypkin)
Keywords: checkin-needed
Comment on attachment 8514918 [details] [review]
GitHub pull request URL (v2.1)

Ah yeah, sorry

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): n/a
[User impact] if declined: user can stuck at the thread deletion waiting screen at some circumstances, so that app should be killed and opened again. 
[Testing completed]: yes, unit tests and manual testing
[Risk to taking this patch] (and alternatives if risky): low, small targeted js change
[String changes made]: n/a
Flags: needinfo?(azasypkin)
Attachment #8514918 - Flags: approval-gaia-v2.1?
Hi Kai-Zhen,
Per comment 5 by Oleg, the patch is also for 2.0M. Please help to land on 2.0M. Thanks!

@Oleg and Steve
Thank you very very much!
Flags: needinfo?(kli)
Attachment #8514918 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Dear Ryan,
Could you please help to apply the patch to 2.0M since Kai-Zhen is PTO? Thank you very much!
Blocks: Woodduck, 1080481
Keywords: checkin-needed
v2.1:  https://github.com/mozilla-b2g/gaia/commit/aa63911ae979ed1e3eab2ba23a6e7d6a59085854
v2.0m: https://github.com/mozilla-b2g/gaia/commit/3b39ec7cd8a849fa2de5091072501c6ae852508c

You need to request v2.0 approval too if you want it to land there.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(kli)
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S8 (7Nov)
Comment on attachment 8514918 [details] [review]
GitHub pull request URL (v2.1)

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #10)
> v2.1: 
> https://github.com/mozilla-b2g/gaia/commit/
> aa63911ae979ed1e3eab2ba23a6e7d6a59085854
> v2.0m:
> https://github.com/mozilla-b2g/gaia/commit/
> 3b39ec7cd8a849fa2de5091072501c6ae852508c
> 
> You need to request v2.0 approval too if you want it to land there.

Thanks! Yeah, if it's not too late, I think it's better to be consistent since fix is safe and has been already uplifted to both v2.0m and v2.1. 

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 #): n/a
[User impact] if declined: user can stuck at the thread deletion waiting screen at some circumstances, so that app should be killed and opened again.
[Testing completed]: yes, unit tests and manual testing
[Risk to taking this patch] (and alternatives if risky): low, small targeted js change
[String changes made]: n/a
Attachment #8514918 - Flags: approval-gaia-v2.0?
Verify OK, this issue can't repro on Woodduck 2.0.
Attached: Verify_1092112.MP4
Reproducing rate: 3/3

Woodduck 2.0 Build:
Gaia-Rev        7bc7f75d712ccef535fd371bfcc7fe61dcdcf874
Gecko-Rev       8f21e6d8abf8ee01d8da066495d8febf3138375a
Build-ID        20141113050313
Version         32.0
Group: woodduck-confidential
Attached video video
I don't want the bug to be confidential because there is a patch that landed here. Can we please make the attachment confidential instead?
Flags: needinfo?(jocheng)
Hi Shine,
No need to make this bug confidential since this bug is not reported by partner directly and no partner data included.

Could you please also verify on 2.1 since status-b2g-2.1 is also "fixed"?
Thanks!
Group: woodduck-confidential
Flags: needinfo?(jocheng) → needinfo?(yue.xia)
Is this a 2.0 regression ? Unless it is I don't think this sounds like a show-stopper for 2.0 at this point and can get fixed in 2.1. Please confirm
Flags: needinfo?(azasypkin)
(In reply to bhavana bajaj [:bajaj] from comment #16)
> Is this a 2.0 regression ? Unless it is I don't think this sounds like a
> show-stopper for 2.0 at this point and can get fixed in 2.1. Please confirm

Nope, it's not regression and it has been already uplifted to v2.1. So yeah, if it's too late we can definitely live without it in v2.0, the only intention was to be in sync with v2.0m.
Flags: needinfo?(azasypkin)
Attached video video
This issue can't repro on Flame 2.1
See attachment: v2.1_video.MP4
Reproducing rate: 0/3

Flame2.1 build:
Gaia-Rev        569a299ca446f714cd98d5881cc058fd6f6e257b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/d188e92aa5a6
Build-ID        20141113001200
Version         34.0
Flags: needinfo?(yue.xia)
Attachment #8514918 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0-
You need to log in before you can comment on or make changes to this bug.