976495 - [Sora][Message][MMS]The prompt message is wrong when deleted a sending message.

Status: RESOLVED DUPLICATE of bug 949801

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

Description

[sync-1]

Firefox OS v1.3
 Mozilla build ID: 20140208004002
 
 DEFECT DESCRIPTION:
 ->MS have a prompt message"Message not found".
 
  REPRODUCING PROCEDURES:
 ->Enter"Message"create a MMS and send;
 ->Long tap the sending MMS and select deleted
 ->After deleting successfully,MS have a prompt message"Message not found",the prompt message is wrong.(ko)
 
  EXPECTED BEHAVIOUR:
 ->Needn't the prompt message.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:100%
 
  For FT PR, Please list reference mobile's behavior:Beetle lite FF long tap messge have no respond.

Comment 1

[sync-1]

Attachment: image

Comment 2

[Julien Wajsberg [:julienw]]

I don't reproduce at least on master.

QA, can you please test on 1.4 and 1.3?

Comment 3

[Cody Roesch [:croesch]]

Unable to reproduce on Buri 1.4. Cannot get an incorrect message when trying to delete a sending MMS message during send process.

Environmental Variables
Device: Buri V1.4 Moz Ril
Build ID: 20140225040205
Gecko: https://hg.mozilla.org/mozilla-central/rev/e3daaa4c73dd
Gaia: e0f39c7179c8b297326c0e2313950610be1f5c52
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg


Will post v1.3 in the next comment after I revert phone and check.

Comment 4

[Cody Roesch [:croesch]]

I AM able to repro this bug in V1.3 latest. When deleting an MMS message while it's sending, I get an error saying message not found.

Environmental Variables
Device: Buri V1.3 Moz Ril
Build ID: 20140225004004
Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/e597280f9300
Gaia: 6e883bde818d4d53aef7b5b075b4b34267918360
Platform Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 5

[Julien Wajsberg [:julienw]]

qawanted for 1.1 now, thanks !

Gene, I think you fixed something about deleting a pending message, but I can't find the bug, maybe you can help finding it?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> qawanted for 1.1 now, thanks !
> 
> Gene, I think you fixed something about deleting a pending message, but I
> can't find the bug, maybe you can help finding it?

Already clarified in the bug. comment 0 says this does not repro on 1.1.

"Beetle lite FF long tap messge have no respond."

Comment 7

[Jason Smith [:jsmith]]

Need input from UX before making a blocking decision here to understand impact & what the expected behavior is.

Comment 8

[Preeti Raghunath(:Preeti)]

So its just that we're seeing wrong message on the phone screen. Is the functionality correct?

Comment 9

[Steve Chung [:steveck]]

v1.1 didn't have the long press behavior (In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Julien Wajsberg [:julienw] from comment #5)
> > qawanted for 1.1 now, thanks !
> > 
> > Gene, I think you fixed something about deleting a pending message, but I
> > can't find the bug, maybe you can help finding it?
> 
> Already clarified in the bug. comment 0 says this does not repro on 1.1.
> 
> "Beetle lite FF long tap messge have no respond."

v1.1 didn't have the long press behavior, so the way to verify it is delete the sending message by entering the message deletion mode(it might be difficult to do so during sending). BTW I can not reporduce this on master either. And I also remember we already applied a gecko patch for this before.

Comment 10

[Julien Wajsberg [:julienw]]

(In reply to Preeti Raghunath(:Preeti) from comment #8)
> So its just that we're seeing wrong message on the phone screen. Is the
> functionality correct?

yes, the deletion is correctly done

(In reply to Steve Chung [:steveck] from comment #9)
> 
> v1.1 didn't have the long press behavior, so the way to verify it is delete
> the sending message by entering the message deletion mode(it might be
> difficult to do so during sending). BTW I can not reporduce this on master
> either. And I also remember we already applied a gecko patch for this before.

Yes :( can you reach Gene and ask him directly?

Comment 11

[Preeti Raghunath(:Preeti)]

UX,

Please renom if needed. Its just a wrong message display.

Comment 12

[Stephany Wilkes]

Flagging Ayman on this. My concern is that the state of the deletion is confusing.

Comment 13

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> (In reply to Preeti Raghunath(:Preeti) from comment #8)
> > So its just that we're seeing wrong message on the phone screen. Is the
> > functionality correct?
> 
> yes, the deletion is correctly done
> 
> (In reply to Steve Chung [:steveck] from comment #9)
> > 
> > v1.1 didn't have the long press behavior, so the way to verify it is delete
> > the sending message by entering the message deletion mode(it might be
> > difficult to do so during sending). BTW I can not reporduce this on master
> > either. And I also remember we already applied a gecko patch for this before.
> 
> Yes :( can you reach Gene and ask him directly?

Gene is OOO this week... maybe Bevis could help with clarification

Comment 14

[Julien Wajsberg [:julienw]]

FTR I don't reproduce on master, I'm flashing a 1.3 build right now to test on this build.

I also found Bug 949801 which looks definitely related, and is not in 1.3. Then I think it's a dupe and Bug 949801 just needs to be uplifted to 1.3. I'm removing the NI for Bevis because I think Gecko did nothing to fix it after all :)

Comment 15

[ayman maat :maat]

(In reply to Stephany Wilkes from comment #12)
> Flagging Ayman on this. My concern is that the state of the deletion is
> confusing.

I cannot reproduce this at the moment (uploading a video of the bug in action would be quite helpful), but based on the comments in this bug i would propose that deletion of a message whilst it is attempting to send is quite an edge case scenario (happy to be corrected if others perceive this as a more common case) …and therefore I would not block on it so referencing comment 11 i personally wont renom at the moment.

However from what i can see I would propose that there is a hole in the current UX. I would suggest that the path for deleting and outgoing message whether sending, sent or failed should be the following:

**PATH**
1) open message app
2) select either to compose a new message or an existing message thread
3) compose a message
4) select send
5) long press on the outgoing message (irrespective of state it is in)
6) select ‘delete’ 

**EXPECTED**
the user is presented with a ‘confirm deletion’ screen before message is deleted. This screen should existed to catch the instance that the user has select delete by mistake. I would propose deletion screen should have the following structure:

<BODY>Delete selected message?</BODY>
<CTAs>Cancel | OK </CTAs>

Selecting ‘Cancel’ takes the user back to the message thread
Selecting ‘OK’ deletes the selected message and: 
       if the message thread still contains other messages
             returns the user back to the message thread with the  
       if the message thread no longer contains other messages
             returns the user back to the message inbox  

**ACTUAL**
if the message thread still contains other messages
       returns the user back to the message thread with the  
if the message thread no longer contains other messages
       returns the user back to the message inbox

Comment 16

[Julien Wajsberg [:julienw]]

(In reply to ayman maat :maat from comment #15)
> (In reply to Stephany Wilkes from comment #12)
> > Flagging Ayman on this. My concern is that the state of the deletion is
> > confusing.
> 
> I cannot reproduce this at the moment (uploading a video of the bug in
> action would be quite helpful),

So it's fixed on master, but not on v1.3, maybe that's why you don't reproduce.

> but based on the comments in this bug i
> would propose that deletion of a message whilst it is attempting to send is
> quite an edge case scenario (happy to be corrected if others perceive this
> as a more common case) …and therefore I would not block on it so referencing
> comment 11 i personally wont renom at the moment.
> 
> However from what i can see I would propose that there is a hole in the
> current UX. I would suggest that the path for deleting and outgoing message
> whether sending, sent or failed should be the following:
> 
> **PATH**
> 1) open message app
> 2) select either to compose a new message or an existing message thread
> 3) compose a message
> 4) select send
> 5) long press on the outgoing message (irrespective of state it is in)

I don't get the "irrespective of state it is in".


> 6) select ‘delete’ 
> 
> **EXPECTED**
> the user is presented with a ‘confirm deletion’ screen before message is
> deleted. This screen should existed to catch the instance that the user has
> select delete by mistake. I would propose deletion screen should have the
> following structure:
> 
> <BODY>Delete selected message?</BODY>
> <CTAs>Cancel | OK </CTAs>
> 
> Selecting ‘Cancel’ takes the user back to the message thread
> Selecting ‘OK’ deletes the selected message and: 
>        if the message thread still contains other messages
>              returns the user back to the message thread with the  
>        if the message thread no longer contains other messages
>              returns the user back to the message inbox  
> 
> **ACTUAL**
> if the message thread still contains other messages
>        returns the user back to the message thread with the  
> if the message thread no longer contains other messages
>        returns the user back to the message inbox

Yep why not. Please answer the comment and I can file another bug.

Comment 17

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #16)
> (In reply to ayman maat :maat from comment #15)
> > 
> > However from what i can see I would propose that there is a hole in the
> > current UX. I would suggest that the path for deleting and outgoing message
> > whether sending, sent or failed should be the following:
> > 
> > **PATH**
> > 1) open message app
> > 2) select either to compose a new message or an existing message thread
> > 3) compose a message
> > 4) select send
> > 5) long press on the outgoing message (irrespective of state it is in)
> 
> I don't get the "irrespective of state it is in".
> 

sorry, by 'irrespective of state is it in' I mean 'Whatever state it is in'. By This i mean whatever state an outgoing message can be in. So therefore:

  - Sending
  - Sent
  - failed

...i dont think there are any others, but if there are please include those as well.

Comment 18

[Julien Wajsberg [:julienw]]

(NI me to remember to file a bug)

Comment 19

[Julien Wajsberg [:julienw]]

Filed bug 981052