1045493 - [Messages] It's impossible to activate recipients input field once all recipients were deleted in expanded mode

Status: RESOLVED WONTFIX

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

Description

[Oleg Zasypkin [:azasypkin][⏰UTC+1]]

It's impossible to activate recipients input field once all recipients were deleted in expanded mode.

STR:
1. Open new message composer;
2. Select several recipients *only* from existing contacts so that recipients are split into several lines (caret and keyboard are visible);
3. Swipe recipients panel down to expand (caret and keyboard are visible);
4. Press backspace to remove all recipients;
5. Blur recipients input field eg. by putting focus into message input field;
6. Try to activate recipients input once again.

Expected result: recipients input field is activated and user can type recipient name or number;

Actual result: it's impossible to activate recipients input field and user can't type recipients name or number, but still can access "add recipient from contacts" button ("+") to pick recipient from contacts.

Comment 1

[Julien Wajsberg [:julienw]]

NI me to test on v1.4 and v1.3.

Comment 2

[Julien Wajsberg [:julienw]]

This happens in v1.4 and v1.3, so it's not a regression and not a blocker.

Actually, I think we have another bug for this.

Comment 3

[Oleg Zasypkin [:azasypkin][⏰UTC+1]]

Attachment: tarako issue

Comment 4

[Oleg Zasypkin [:azasypkin][⏰UTC+1]]

v1.3t is affected too with some visible effect (see attachment 8463891 [details])

Comment 5

[Julien Wajsberg [:julienw]]

Yes, same effects in v1.3 and v1.4.

Comment 6

[Luke Chang [:lchang] (inactive)]

Take this bug since my patch in bug 1050682 seems to be able to resolve this issue.

Comment 7

[Luke Chang [:lchang] (inactive)]

Hi Oleg,

After bug 1050682 is landed on master branch, I confirm that this bug is fixed together.

However, I'm not sure if I need to uplift the patch of bug 1050682 to other branches since there isn't any blocker flag yet. Do we nominate them?

Comment 8

[Oleg Zasypkin [:azasypkin][⏰UTC+1]]

Hey Luke,

(In reply to Luke Chang [:lchang] from comment #7)
> Hi Oleg,
> 
> After bug 1050682 is landed on master branch, I confirm that this bug is
> fixed together.

Great!

> However, I'm not sure if I need to uplift the patch of bug 1050682 to other
> branches since there isn't any blocker flag yet. Do we nominate them?

Yeah, we usually nominate if we think it's a blocker and it's confirmed or not during triage. Regarding to this one - I remember that we agreed that it doesn't look like a blocker (see comment 2). Also "updateMode" function where your fix is incorporated is available in master only, so for other branches we'll need another patch :)

Thanks!

Comment 9

[Luke Chang [:lchang] (inactive)]

Oleg, Thanks!


Set "unaffected" to v2.1 since it's already fixed by bug 1050682. 

Nominate it as v2.0? because a user will be not able to type any characters or numbers in the recipient field after doing the STR in comment 0.

Comment 10

[Julien Wajsberg [:julienw]]

Note to triage: this is not only uplift bug 1050682, as I understand it we'd need a branch patch here.

I wouldn't block on this: it's happening for a long time (v1.3 is affected), and there is an easy work around (press "back" to move to the thread list, and "new message" again).

Comment 11

[Preeti Raghunath(:Preeti)]

Moving to backlog as it is seen in 1.3/ 1.4

Comment 12

[Luke Chang [:lchang] (inactive)]

Attachment: Pull Request for v2.0

Hi Steve,

This patch is for v2.0 branch. Could you help reviewing it? Thanks.

Since this bug is not a blocker, please take your time.

Comment 13

[Steve Chung [:steveck]]

Comment on attachment 8474375 [details] [review]
Pull Request for v2.0

r=me, thanks. Please remember to request approval for 2.0 uplifting.

BTW I think it still worth to uplift with small patch and no side effect concern. Although it's not totally block usability, it still make user frustrated if recipient unable to be added at that moment.

Comment 14

[Luke Chang [:lchang] (inactive)]

Hi Steve, 

Thanks for reviewing. I'll request approval once TBPL is passed.

Comment 15

[Luke Chang [:lchang] (inactive)]

Comment on attachment 8474375 [details] [review]
Pull Request for 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 #): an existing bug since v1.3
[User impact] if declined: a user will be not able to type any characters or numbers in the recipient field after doing the STR in comment 0.
[Testing completed]: yes.
[Risk to taking this patch] (and alternatives if risky): should be low since there's already a similar patch (bug 1050682) landed on master branch for a while.
[String changes made]: none.

Comment 16

[bhavana bajaj [:bajaj]]

(In reply to Luke Chang [:lchang] from comment #15)
> Comment on attachment 8474375 [details] [review]
> Pull Request for 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 #): an existing bug since v1.3
> [User impact] if declined: a user will be not able to type any characters or
> numbers in the recipient field after doing the STR in comment 0.
> [Testing completed]: yes.
> [Risk to taking this patch] (and alternatives if risky): should be low since
> there's already a similar patch (bug 1050682) landed on master branch for a
> while.
> [String changes made]: none.

We are past the timeline to land any non-blocking changes on 2.0 at this point, so we are kinda late at this point :(

Comment 17

[Luke Chang [:lchang] (inactive)]

Comment on attachment 8474375 [details] [review]
Pull Request for v2.0

Clear request flag since I should avoid adding any risk for regressions on 2.0 at this point. Sorry about that.

Comment 18

[Luke Chang [:lchang] (inactive)]

Close it as WONTFIX since v2.1 isn't affected and it won't be landed on v2.0.