Bug 1939403 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Some special chars in folder names cause them to be created with a
hashed URI component, instead of an escaped URI component. Our lookup
code was checking only for the escaped case.

Instead of trying to guess the correct URI, this patch searches for the
folder based on its name.

More information are available in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1939403#c2
Some special chars in folder names cause them to be created with a
hashed URI component, instead of an escaped URI component, and tag
handling is currently broken for such tags.

Steps to reproduce:
* enable tags mode in the folder pane
* context click on a tag and select "manage tags"
* create a tag "6: Test"
* verify the new tag is listed in the folder pane
* return to the tag managment tab and edit the newly created tag
* rename it to "6: Test2"
* observe the tag not being renamed in the folder pane
* disable and re-enable tags mode in the folder pane
* observe the new tag no longer being listed at all

The failure is do to [1] failing to return the correct URI. There is
also a problematic behavior of `folder.createLocalSubfolder(name)`: The
URI of the new folder will be derived from the provided name, it will be
sanitized and hashed. However, it is currently not possible to known in
JavaScript, what the final URI will be before the call. It is therefore
not possible to check if the folder exists already (its name can be
anything, unrelated to the used URI and not helpful).

This issue was revealed through our WebExtension APIs, which call
`SmartMailBox.getSmartFolder()` and `SmartMailBox.getTagFolder()` and
started throwing errors when tags with special chars were used.

This patch tries to solve these issues as follows:
* catch all errors in `SmartMailBox.getSmartFolder()` and
`SmartMailBox.getTagFolder()`, make them return `null` if the folder
could not be retrieved.
* make these functions also handle the "folder is missing case"
* change callers to properly handle the case of no folder being returned
* keep track of URIs of created tag folders in an internal map
* replace [1] by looking up the known URI from the internal map
* remove obsolete tag folders to reduce the possibility of trying to
create a folder which exists already

[1]: https://searchfox.org/comm-central/rev/60cb4d34e57188de3d5ad005640913d189647893/mail/modules/SmartMailboxUtils.sys.mjs#245-258

Back to Bug 1939403 Comment 3