Closed Bug 1134987 Opened 9 years ago Closed 6 years ago

[email] Deal with the presence of duplicate special folders better; for example the true gmail sent folder and sent folders created by confused IMAP clients

Categories

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

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: asuth, Unassigned)

References

Details

For both of the reported problems on bug 1134750, a situation was occurring on gmail where other IMAP clients had created misleading 'sent' folders and users thought we weren't synchronizing the sent folder correctly because they were selecting the false folder.

===== Data

For example, folderSync reported the following in one of the cases:

imap:folder-sync:add {"type":"sent","name":"Sent","path":"Sent","delim":"/"}
imap:folder-sync:add {"type":"sent","name":"Sent Mail","path":"[Google Mail]/Sent Mail","delim":"/"}

Note that the user is from a European locale; for my test account the canonical sent mail folder is ""[Gmail]/Sent Mail".  I believe the gmail/googlemail thing is an outgrowth of the time period when Google ran into an existing "gmail" provider in Germany and wasn't allowed to use gmail there.

And it sounds like in the older case, the fake folder we were dealing with was "[Imap]/Sent".

==== The problems

1) Back-end: We use getFirstFolderWithType() all over the place, and we may obviously make the wrong conclusions about which folder to use.  In the gmail case, it's not actually a problem for us because we let gmail put the sent mail in the sent folder.  So our decision does not matter.

However, it arguably would be good for us to improve our heuristics.  Presumably the wrong folder doesn't have the special-use flag reported by the server and it's just named-based inference deciding the folder is a sent folder.  We could avoid the name-based fallback in that case.  Also, for gmail, except for that "Gmail"/"Google Mail" duality, things should be pretty clear cut.  (And gmail inhibits creation of folders that are any localized variant of its special folders, however I'm not sure how that interacts with "path/segments/".)

2) UI: In the bug 1134750 cases it's more a question of sort order logic and limited screen size.  In the first problem case, the user has 18 folders.  The true sent folder "[Google Mail]/Sent" is going to lose to the false sent folder "Sent" because mailbridge.js only applies sort priorities within hierarchy (to avoid weird indentation, mainly).

If we make the back-end smart enough to know the "true" sent folder, we could do some folder ordering magic to just make it synthetically live at the root/etc.  Of course there's still the problem of the false folder living right there too.  And we can run into l10n issues and other bug reports like "uh, I have 2 sent folders and only one of them gets localized and that's weird".

==== (Too) Fancy

The nice things we could do here that are hard and somewhat too complex for us right now are:

- Create a unified folder and quietly smash the folders together.  This would depend on us being somewhat good at identifying erroneous sent folders.  We wouldn't want to run afoul of folder schemes where the user has folders like "grandma/received", "grandma/sent", "bob/received", "bob/sent", and then unify all the sent folders.  We'd fall over and it's not what the user wants.

- Offer to help the user fix up their folder situation.  This becomes tricky because:
  - It's possible the user still uses whatever the misconfigured client is and the stupid folder will keep coming back.
  - On gmail we have MOVE and direct label flag manipulation that allows us to efficiently move the messages without a big hassle.  But on other servers without MOVE there's potential risk for us crashing/being closed halfway through a copy-then-delete scenario.  The flip side is that on a non-gmail server we hopefully would be less likely to have multiple sent folders.  However it's still possible for there to be "Sent" and "Sent Mail" since special-use folders are somewhat new and not all things support them.

===== Feedback seeking

Because of the ActiveSync "junk" folder heuristic bug 1134750 which needs to happen for v2.2, it's worth talking about this a little right now, at least the back-end stuff.  So :jrburke, uh, what do you think?  (I'm kinda suspecting you might just be for lofting all of the special folders to the root and the user would just see 2 sent folders and be confused/annoyed but at least have some hope of finding their sent mail.)
Flags: needinfo?(jrburke)
You suspect correctly! I shall have to vary my preferences to keep you off-guard in the future.

It does create some dissonance, but the dissonance is hopefully an "early error catch". They can know up front there is a type of duplicate folder but by checking the contents of either to figure out the right one.

The downside is possible earlier recognition of the dissonance, but the upside is avoiding the type of confusion as indicated in bug 1134750.

Since they can actually test each folder next to each other, then at least they can find their mail and just have a lingering question about what looks like duplicated folder names but not be as concerned as not being able to find mail.

Also, a small correction: the ActiveSync "junk" folder is bug 1128883.
Flags: needinfo?(jrburke)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.