(In reply to Jorg K (GMT+2) from comment #59) > Thanks for your comments, Ehsan. > > If you want to deliberate about what the real/actual problem is, here's my > view: > > The root issue is that storageAccessAPI permissions are stored for non-web > origins, that is MailNews schemes like imap: or mailbox:. Do I read comment > #48 correctly and we agree on that? Quote: *"no it doesn't make sense for > principals representing imap/mailbox/or any other non-web URIs to have an > origin"*.
That is _one manifestation_ of the problem, but not the root issue. The root issue is that the permission manager allows storing permissions for any URI scheme for any permission type. The `storageAccessAPI` permission type just happens to be the type of permission that trickled the bug in this case, but if some other code today or tomorrow saves other permission types for some other unexpected URI scheme in the permission manager database you'd more or less have the exact same effect as a result. > I in fact know that TB needs image permission for http(s) and chrome schemes and nothing else. I don't know what other permissions are needed under the hood for the underlying Mozilla platform code, so in that sense the patch could have been quite fatal ;-) Your patch modifies SeaMonkey behaviour as well... If you're going to rely on this knowledge, you should probably formalize the expectations in the form of some `MOZ_RELEASE_ASSERT`s that crash Thunderbird and SeaMonkey if any code ever violate your expectations accidentally, and write some code to migrate the permission manager database for existing installations since those may include the types of permissions which newer builds may crash upon loading. Given that SeaMonkey should probably have a superset of Firefox's behaviour, and no such expectations exist for Firefox, I have a very hard time that this is a productive path to coming up with a good solution for this problem, but you're welcome to pursue it. > So would you accept a patch for TB (with #ifdef) to suppress storageAccessAPI types for non-http(s): and chrome: schemes when reading the permissions back from the database and potentially also a part that would prevent those permissions from being stored in the first place? That's my preferred solution. No, that's a wallpaper solution that doesn't address the underlying problem. As I explained above, any patch that tries to solve this at the level of the permission manager needs to crash Thunderbird and SeaMonkey for invalid input into permission manager and upgrade the database. Again, this is *not* a good direction to solve the problem. > Continuing the deliberation on the real problem: > > The next issue is that the permissions manager instantiates nsIURI objects > when restoring the permissions from the database. > > The next issue is that creating a new imap: URI runs a lot of MailNews code, > https://searchfox.org/comm-central/rev/364e5ba7492c8a13e104662a7e43769819e339f7/mailnews/imap/src/nsImapService.cpp#2375 > including handling/initialising folders and hence trying to get localised > strings and store them in static memory **before** those strings are actually > available. > https://searchfox.org/comm-central/rev/29706036071c4629c2b44512d1acecb64008cc46/mailnews/base/util/nsMsgDBFolder.cpp#2727 > > This part could be rephrased to saying: The problem is that the permissions > system is initialised before the language pack loads. I understand all of this, and I think you need to think a bit outside of the box here. Think about what would have happened if it wasn't the permission manager, but (for example) PSM, or DOM storage, or safebrowsing, etc. etc. etc. which were trying to process a URI at startup and somehow ended up having an imap URI on their hand. It's not even possible to find all such dependencies, let alone fix every single similar bug by adding custom workarounds like the one you're suggesting here. What I'm trying to suggest to you instead is to figure out the actual requirements of the IMAP service, whatever they may be, and write the proper code to ensure that all dependencies are loaded _before_ we need to process our first IMAP URI. That way you wouldn't need to touch the permission manager at all, and neither would you need to worry about other similar cases where this problem may be showing up. In other words... > I don't know how you envisage to achieve (quote) *"making the code that is > reading this string wait on the loading of the thing that it is depending > on"*. Permissions code, MailNews folder initialisation code and loading the > strings from the language pack are completely independent. All I can imagine > is to listen to some "mail-startup-done" event and re-reading the > strings/folder names then. > > So where from here? ... make the code reading this string (the IMAP service) wait on the thing it is depending on (the localized strings) to become available[1]. :-) [1] Maybe my understanding is overly simplistic here and there is a bit more to it which was why I was so vague previously. I hope now I've explained the idea I'm going for better. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847772 Title: E-mail folder names are not localized in thunderbird 68 To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1847772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
