When starting Thunderbird the folder pane tries to restore the last selected folder. However if this belongs to an extension which has become disabled or simply not yet started up then the RDF service is unable to create a folder object, instead returning a plain RDF resource. Unfortunately this resource then pollutes the RDF cache preventing the extension from loading correctly.
If the folder scheme has a registration then this means that the extension has loaded and it's safe to attempt to get or create the folder. At some point the folder lookup service will need to create the folder itself so it's going to need to do something along these lines anyway. To avoid code duplication I called getOrCreateFolderForURL from getFolderForURL but I can change that if you prefer.
Attachment #9029953 - Flags: review?(acelists)
(On ESR60 the specific problem that shows up the most is the folder pane trying to restore folders that aren't available yet, thus the extra code to deal with that case.)
Comment on attachment 9029953 [details] [diff] [review] Proposed patch Review of attachment 9029953 [details] [diff] [review]: ----------------------------------------------------------------- Thanks. This may slow down getOrCreateFolderForURL a bit, but we aim to not call it from places where creating the folder is not needed.
Attachment #9029953 - Flags: review?(acelists) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/comm-central/rev/b8dbd330b2a1 Don't try to create folders for unloaded extensions. r=aceman
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
Comment on attachment 9029964 [details] [diff] [review] ESR 60 What's the risk here?
Sorry for the delay, I hadn't got around to testing the port yet because I needed to rebuild my branch tree. (In reply to Jorg K from comment #5) > What's the risk here? This is just a correctness check to avoid creating a plain RDF resource (which is what we would get if we don't have an appropriately registered component) when we don't want one anyway, so the risk should be low. Additionally, lots of branch is still hitting RDF directly, so I'm only patching the minimum number of calls to minimise the issue, rather than trying to port all of kill-RDF. Additionally the code is in the startup path so if there was a problem it would have been very noticeable.
Let's take it for TB 60.4.n, n > 0, or TB 60.5.
Comment on attachment 9029964 [details] [diff] [review] ESR 60 Good for TB 60.5.
Attachment #9029964 - Flags: approval-comm-esr60+
You need to log in before you can comment on or make changes to this bug.