997496 - [Email] Undoing a tagging operation (marking as read, flagging/starring) inverts the tagging operation; confusing when some of the source messages already had the target state; ideally avoid that by partition/overwork avoidance

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, enhancement)

Description

[Joshua Mitchell (Inactive)]

Attachment: Undo.mp4

Description:In the email app, when in edit mode you are able to select multiple emails and apply certain flags to them. If you select both Read and Unread emails, then select the 'mark as read / unread' but then attempt to undo, all the selected emails will end up being marked as read.

Repro Steps: (with email already set-up)
1) Update a Tarako to BuildID: 20140415004002
2) Select Email
3) Select Edit
4) Select both a read and an unread email
5) Select 'mark as read / unread'
6) Select undo

Actual:
Both messages are marked as read
Expected:
Both messages will remain in their original state

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140415004002
Gaia: 44ff6248c28ff83b9ad1161847a176399f93d3bb
Gecko: 28aea220e338
Version: 28.1
Firmware Version: SP6821

Notes: This bug was seen while testing around a test case but did not fail a test case directly
Repro frequency: 100%
See attached: logcat.txt, Undo.mp4

This DOES repro on the 1.3 Buri
1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140414004002
Gaia: 8b92c56267fe50772095f1f25d6cc1f9c9966eb4
Gecko: 3e26908fca71
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 1

[Joshua Mitchell (Inactive)]

Attachment: logcat.txt

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Great edge-case detecting work!  This affects all versions of the mail app.  This does not constitute a regression and is pretty edge-casey, so I think it makes sense to work this on trunk as a medium-to-low priority.  If it was easier to trigger our batch manipulation actions in a way that affected messages, I'd rank it higher.  Right now I think the biggest risk is a user who selects messages for flagging or read/unread hitting the other button instead since that's more likely to result in a heterogeneous mixture of messages.

The backend views tagging operations as "add FOO to this set of messages" and "remove BAR from this set of messages".  The undo operation just inverts that action to be "remove FOO from this set of messages" and "add BAR to this set of messages."  Note that if the user hits the undo button before we perform the action on the server then the state of the messages on the server will *not* be affected, and our local state will just be wrong until we next synchronize the message states.

The concept of undo becomes sketchy when some of those messages already had FOO on them or didn't have BAR.  It's a bit silly for the user 

I think the simplest implementation issue is for us to filter-out messages from a requested operation that already have the target state when generating the job.  The potential issues with this would be:

- If we are out-of-sync with the server such that some of the messages we think already have FOO applied no longer have FOO applied, then those messages may end up without FOO applied.  There's no clear correct answer in this situation, but a good argument of this proposed behaviour is that if the user used another device to remove the tags, they probably meant to remove those tags and it's good if they stay removed.

- We need to figure out what to report number-wise in this situation.  Do we still claim we're affecting 10 messages if only 2 actually need changes?


Alternate implementations would include persisting the original message states when we perform the operation on the server.  This would complicate things a good deal and slow down our ability to perform the flag changes, so I'd generally suggest we not do this.

Comment 5

[BMO Automation]

Firefox OS is not being worked on