1149345 - [Messages][Threads] Images can be attached to incoming messages, and corrupt the thread it was originally meant for.

Status: RESOLVED WONTFIX

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

Description

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Description:
When attaching an image to a message, and then tapping a notification to access another thread and taping done on the attachment, the image will be attached to the new thread, instead of the thread that the user was originally in. This will also cause the thread to become corrupted on 3.0 and 2.2. The user will have to delete the entire thread before they are able to successfully send an MMS or SMS to that contact.

Prerequisite: Have at least 1 message thread in the messages app


Repro Steps:
1) Update a Flame to 20150330010204
2) Open Messages App
3) Begin attaching an image
4) When reaching the image crop screen, receive an sms from another number
5) Tap the notification, and then quickly tap done
 

Actual:
The user is opened up to the thread from the notification, but the image is placed in this new thread. The thread that was originally entered  has the draft automatically discarded


Expected:
The user is not able to tap the done button when tapping the notification to a different thread, and the draft is not discarded without a confirmation prompt

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330010204
Gaia: be25b16efa19bab8d54be08f8fe45dcc93bf93d0
Gecko: dfe60814eda7
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 5/5
See attached: Logcat, Video - https://youtu.be/FrzaQABAGcg

Comment 1

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This issue DOES repro on Flame 2.2, 2.1, and 2.0

The user is opened up to the thread from the notification, but the image is placed in this new thread. The thread that was originally entered  has the draft automatically discarded

Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330002503
Gaia: 473cd63f53c855299b719285d9b95e3f2910782f
Gecko: 4b13c4254e2f
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330001204
Gaia: 6f39e4e876152de1dcdcc0e7656197f22f105e4b
Gecko: 275ad18f587b
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330000204
Gaia: 896803174633fc6acd3fd105f81c349b8e9b9633
Gecko: 0dd313c30aa9
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

QAwanted for Logcat

Comment 3

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
This is an edge case that ends up in corrupted data, I think this may occur often in the wild but depends on timing.  NI on component owner for nomination decision beyond 3.0.

This also may be a windows management issue, NI on that component owner as well to take a look.

Comment 4

[Gerry Chang [:gchang]]

NI message owner for more information.

Comment 5

[Julien Wajsberg [:julienw]]

Good finding !

There are actually ways to work around this issue, but we'd need UX input to know the best UX here.

Possibilities:
A. tapping on the notification do nothing while selecting an attachment
B. tapping on the notification will cancel the attachment selecting, save draft and move to the new thread.


Omega, since Jenny is in PTO, I'll defer to you: what do you think?

Comment 6

[Shine(Leave from Mozilla)]

(In reply to Derek Harris [:DerekH] from comment #2)
> QAwanted for Logcat

I have reproduced this issue on latest build of Flame 3.0 by the STR in comment 0.
See attachment: logcat_1636.txt & Flame3.0_video.MP4
Found time: 16:36
Rate: 5/5

Device: Flame 3.0 (Affected)
Build ID               20150330160204
Gaia Revision          be25b16efa19bab8d54be08f8fe45dcc93bf93d0
Gaia Date              2015-03-29 10:19:00
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/6dedce1ca673
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150330.191926
Firmware Date          Mon Mar 30 19:19:35 EDT 2015
Bootloader             L1TC000118D0

Comment 7

[Shine(Leave from Mozilla)]

Attachment: logcat_1636.txt

Comment 8

[Shine(Leave from Mozilla)]

Attachment: Flame3.0_video.MP4

Comment 9

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Possibilities:
> A. tapping on the notification do nothing while selecting an attachment
> B. tapping on the notification will cancel the attachment selecting, save
> draft and move to the new thread.

B looks the better one I think.

Comment 10

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> B. tapping on the notification will cancel the attachment selecting, save
> draft and move to the new thread.

Julien, do you have any specific workaround in mind that allows us to cancel inline activity (Gallery) from the app that initiated it (Messages)?

Comment 11

[Julien Wajsberg [:julienw]]

I thought we had a MozActivity.cancel() but I see we don't...

Therefore we're left with previous A, or a new :

C. Let the user finish the activity, then save draft, then move to new panel.

But I don't like this because when the user presses the notification it would be like A with no way to give a feedback.

NI Fabrice who might have some idea to handle such cases.

Comment 12

[[:fabrice] Fabrice Desré]

Indeed we don't have a way to cancel an ongoing activity. That would also be a strange UX (why did my image picker app close?) I think.

So I don't have a really better idea, it seems like ideally we need to maintain the editing/viewing state of several threads. I have no idea how hard this is to implement though.

Comment 13

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

triage: blocking

Comment 14

[Julien Wajsberg [:julienw]]

Thinking of another solution:

D. when the user clicks on the notification, we switch to the other thread behind the activity (so the user sees nothing).
   When the user selects an image and control goes back to the SMS app, the thread from the notification is displayed, but the selected image is saved in a draft for the previous thread (along with any message that was there before).

The behavior is very close to C.

NI jenny to give some advice.

jenny, can you give us your prefered behavior? Then we'll see what are the technical issues. Maybe with the v3 architecture there are new ways to solve this as well.

Comment 15

[Jenny Lee]

Hey Julien and Fabrice,

For the best possible UX, I would really like to have MozActivity.cancel() and go with option B mentioned in comment 5. 

The reason is that, if user taps on the new message notification during an ongoing selection activity, the new message will be of higher importance to the user at the moment, otherwise user would probably not tap on the notification and continue the selection process, naturally we don't want the activity to get in the way under this circumstance. Also, having NO feedback upon tapping on the notification is not intuitive at all, so I wouldn't go that way unless we have no choice.

Let me know, thanks!

Comment 16

[Julien Wajsberg [:julienw]]

Wondering if it would make sense for the System to always cancel the activity when taping the notification? Or even when "launch()ing" an app?

I don't know if the System has this capability.

NI alive and Michael on this. What are your thoughts, guys?

Comment 17

[Michael Henretty [:mikehenrty][:mhenretty]]

Personally, I would rather it be up to the app initiating the activity to be able to cancel the request. This was the best solution for bug 1122205, which may also block 3.0.

From a UX perspective, I think it's much more annoying to both the app and the user if we cancelled activities when tapping notifications. If the app is allowed to cancel the request, it is up to the app to make sure that is not an annoying thing to do.

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

Michael said. (Had a discussion in bug 1122205 too)

Comment 19

[Julien Wajsberg [:julienw]]

I wasn't aware of that bug, this looks like to be exactly the same issue. Maybe we should dupe?

We'll need several bugs though: likely one for Gecko/System and one for SMS app (and maybe other apps ?).

Comment 20

[Doug Sherk (:drs) (inactive)]

Bhavana, this should block Spark.

Comment 21

[Julien Wajsberg [:julienw]]

Doug, do you encounter this issue often enough so that it's deemed important for Spark?

FTR I dogfood for 1.5 years, I use the SMS app a lot, and never encountered this issue once. Likely because when I'm doing an action (here selecting an image so that we can attach to a new message) I'm unlikely to click an incoming message notification.

Moreover this issue doesn't corrupt existing data.

I'll be really happy when we get the activity.cancel operation in bug 1122205 and I'd be glad to fix this bug ... yet is it a good candidate for being a spark blocker?

I'd like to see arguments here instead of affirmative sentences.

Comment 22

[Doug Sherk (:drs) (inactive)]

Sure, thanks for the really detailed feedback.

Comment 24

[Gregor Wagner [:gwagner]]

[Blocking Requested - why for this release]:

Comment 25

[Johan Lorenzo [:jlorenzo]]

Comms triage: Real edge case with data corruption. Let's put it at the top of the priority.

Comment 26

[Julien Wajsberg [:julienw]]

The data corruption part of this bug (deleting the draft) may be fixed by the work in bug 1176976.

Comment 27

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 28

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(