(Following on from Bug 1588391)

Folder URIs seem to be inconsistantly-encoded. And while we can tighten that up (see Bug 124287 comment 26), we'll still need to deal with the inconsistency in existing code and data (eg, virtualFolders.dat stores folder URIs).

So for now it probably makes sense for the folder lookup service to normalise all lookups,
eg:
imap:INBOX/foo bar should equate to
imap:INBOX/foo%20bar (but not to imap:INBOX%2Ffoo%20bar!).

(And once this is done, we should backout the imap-specific check added by attachment 9101200 [details] [diff] [review]).

Yes, landed at: https://hg.mozilla.org/comm-central/rev/7fc4bc60717a#l1.19

(In reply to Jorg K (CEST = GMT+2) from comment #1)

Yes, landed at: https://hg.mozilla.org/comm-central/rev/7fc4bc60717a#l1.19

next step?

(In reply to Wayne Mery (:wsmwk) from comment #2)

next step?

Next steps:

• drastically tidy up and overhaul the way folders are created (and ban dangling folders entirely!).
• make sure folders are all ultra-careful about how they encode strings for their URI, name, prettyname etc... (Bug 124287)
• remove the folder-lookup-service entirely (replacing it with a single lookup function on the account manager) (Bug 1734254)

All of which rather render this bug redundant :-) So perhaps we just close it?
When I get a chance to look at this stuff properly I'll pull together all the existing bugs and wrangle them into a coherent plan.

I was thinking make this a meta bug. But WOW, bug 124287 is a monster meta.

Are there also implications for add-ons?

@Wayne: I had fixed at least one bug in the WebExtension API, which was due to invalid characters, so yes. Do you need the bug number?

(In reply to Wayne Mery (:wsmwk) from comment #4)

I was thinking make this a meta bug. But WOW, bug 124287 is a monster meta.
:-) It is a good one, isn't it?
I think most of those bugs melt away once the code is really clear about how names are being used (eg as filesystem paths, URIs, display names, IMAP folder name etc etc). Each domain has pretty clear rules on what's valid, and what encoding/escaping is required. The folder-creation deals with with a big chunk of this.

Are there also implications for add-ons?

The MailFolder API looks like it shields the extension from most of the sharp edges. I think mostly the extension API will just operate as expected - and without the current fear of certain characters screwing things up. Some folder paths will change - there might be some URI escaping applied where it currently isn't. But extensions are discouraged from guessing/manipulating path strings anyway. Extensions which save path strings across sessions might need a little work?

Extensions which save path strings across sessions might need a little work?

I hope, that the modified internal path sanitization will return the correct/new paths even for stored old path strings. If not, we will have to make an announcement.

It would be of course great, if the change to the folder system would introduce a UUID for folders which we could use to reference them. Currently, we use the actual path information, but I would rather have the path just be an attribute of the folder and not its id. Do not know how feasible that is of course, but asking is free :-)

(In reply to John Bieling (:TbSync) from comment #5)

@Wayne: I had fixed at least one bug in the WebExtension API, which was due to invalid characters, so yes. Do you need the bug number?

If you remember it.