Launchpad has imported 60 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1575512.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-08-21T11:09:45+00:00 De-berberich wrote: Created attachment 9086978 French locale + German language pack.png standard folders stay French Steps to reproduce: Download and install French locale of Thunderbird 68.0-candidates/build4. Install German de.xpi (and/or American-English en-US.xpi or Italian, ...etc) language packs. Open the config editor, create a new string preference, name it intl.locale.requested and enter the value "de" (or "en-US" or "it", ...etc) without quotation marks. Restart Thunderbird. Actual results : The Thunderbird GUI now is in German (or English or Italian) excepting the names of the default folders in Folder Pane. Expected results: Folder names should be translated, too. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/0 ------------------------------------------------------------------------ On 2019-08-21T11:18:49+00:00 Jorg K wrote: But the localised versions work, right? Just not the changes with the language pack? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/1 ------------------------------------------------------------------------ On 2019-08-21T13:30:41+00:00 De-berberich wrote: Everything in the localized versions works correctly, tool bars and menus in Main window, address book and compose windows. It's just the folder names in the folder pane which resist to translation and keep the original French names of my (French) Thunderbird version when I switch from French to German or English or Italian..... Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/2 ------------------------------------------------------------------------ On 2019-08-21T17:48:54+00:00 Jorg K wrote: What happens with en-US TB plus language pack? Do the folders remain in English? (I can try that myself when I find a moment.) Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/3 ------------------------------------------------------------------------ On 2019-08-21T21:40:47+00:00 De-berberich wrote: I did further tests with the en-US and German versions of TB 68.0 in new separate profiles, installing two or three other language packs. I could not reproduce the issue. Each time I switched to another language and restarted TB the folder names would be translated correctly. Seems to be a problem of the French TB 68.0 version. I'll continue testing the French version in a new profile without installing any add-ons. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/4 ------------------------------------------------------------------------ On 2019-08-21T21:46:58+00:00 Jorg K wrote: Thanks for spending time with this issue. So localised to German + langpack also works. That's good to know. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/5 ------------------------------------------------------------------------ On 2019-08-22T14:13:46+00:00 De-berberich wrote: Created attachment 9087406 TB en-US + de.xpi.png folder pane staying in English Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/6 ------------------------------------------------------------------------ On 2019-08-22T14:24:29+00:00 De-berberich wrote: I continued testing and trying to reproduce this issue. First I recreated a new identical profile for the French version with the de.xpi and en-US.xpi language packs. After hours of testing I suddenly had the Folder Pane in French after switching to German (de) in intl.locale.requested but I still couldn't identify what triggered the error. Then I re-tested the en-US version of Thunderbird with the fr.xpi and de.xpi language packs in a new profile. Eventually with this version I succeeded to provoke the same error : the Folder Pane staying in US-English after switching to German (de) which I documented in an new screen shot. But as in the other profiles I was unable to identify the factor which triggers this error. I've been working for years with language packs but I've never before encountered this issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/7 ------------------------------------------------------------------------ On 2019-08-22T18:00:19+00:00 De-berberich wrote: Created attachment 9087471 TB 69.0b4 fr + de.xpi.png Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/8 ------------------------------------------------------------------------ On 2019-08-22T18:20:23+00:00 Dkl-7 wrote: The content of attachment 9087471 has been deleted for the following reason: Requested by attachment author Eckard Berberich Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/9 ------------------------------------------------------------------------ On 2019-08-22T21:22:21+00:00 De-berberich wrote: Created attachment 9087541 Test TB 69.0b4 fr + de.xpi.png Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/10 ------------------------------------------------------------------------ On 2019-08-22T21:22:44+00:00 De-berberich wrote: Oddly enough today again while testing Thunderbird 69.0b4-candidates/build1/ French version with German language pack de.xpi I could reproduce the error (Folder Pane being fixed in French) but I still can't find a common trigger for this issue (see screen shot). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/11 ------------------------------------------------------------------------ On 2019-08-23T20:57:00+00:00 De-berberich wrote: And here is one more example of the same issue, again in a newly created profile for Thunderbird 68.0 fr in which I have installed • the de.xpi and en-US.xpi language packs; • the English United States Dictionary 60.1webext by Jorg K and German Dictionary 2.0.6.1webext by KaiRo (no French dictionary since it is included in French TB versions); • The add-ons Lightning 68.0b6, Phoenity Buttons 3.1, Provider for CalDAV & CardDAV 1.2, TbSync [Beta Release Channel] 2.3. This time I could observe that the "freeze" of the folder names in French happened after I had changed the language in Preferences (Options) > Composition > Spelling > Language. I now remember that in my second case, too, the selection of the spelling language (at that moment no language had been selected) had preceded the "freeze" of the folder names in French. But this cannot be the only condition, there must be other factors that favor the freeze. Since once the folder names are frozen there is no way to display them in English or German by fiddling the intl.locale.requested value in the config editor or changing the spelling language. I still have another TB 68.0 fr test profile with the same configuration and the same add-ons in which I can't provoke the error. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/12 ------------------------------------------------------------------------ On 2019-08-23T20:59:21+00:00 De-berberich wrote: Created attachment 9087852 TB 68.0 fr + de.xpi.png Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/13 ------------------------------------------------------------------------ On 2019-08-30T17:45:32+00:00 De-berberich wrote: Eventually I could solve this issue after looking up the TB 68 release notes https://www.thunderbird.net/en-US/thunderbird/68.0/releasenotes/ Under "What's New" I found "Language packs can now be selected in the Advanced Options. Preference intl.multilingual.enabled needs to be set (and possily also extensions.langpacks.signatures.required needs to be set to false)" Just like in Firefox 68 the UI language can now be changed in TB 68 via Preferences (Options) > Advanced > General > Language .... To display the "Language" item in "General" you first have to toggle the value of the preferences (options) "intl.multilingual.enabled" and "intl.multilingual.downloadEnabled" from "false" to "true" and restart TB. Language packs must then be downloaded from http://ftp.mozilla.org/pub/thunderbird/releases/68.0/ and installed manually since the feature "Select a language to add..." in "Thunderbird Language Settings" actually doesn't display any languages. Following these instructions in a new pristine profile I could not reproduce the issue described in comments #1 to #13. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/14 ------------------------------------------------------------------------ On 2019-09-01T18:17:11+00:00 De-berberich wrote: Created attachment 9089748 TB 68 - 5th profile.png Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/15 ------------------------------------------------------------------------ On 2019-09-01T18:17:58+00:00 De-berberich wrote: Unfortunately my joy with the new profile created three days ago as described in comment #14 didn't last. Today after changing the UI language in Preferences (Options) > Advanced > Language and restarting TB the folders in the Folder Pane again stayed in French and wouldn't be translated to the new UI language. I have no idea how this issue is triggered. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/16 ------------------------------------------------------------------------ On 2019-09-09T08:31:08+00:00 De-berberich wrote: Update: I think that I've found a possible culprit for this issue of the non-localized folder names when using language packs (German de.xpi and US-English en-us.xpi in the French Thunderbird version in my case). Yesterday again in my actual TB 68 test profile, after switching the GUI language to German or US-English and restarting TB, the folder names would stay in French instead of being localized in German or English. Since I backup all my TB profiles every day, I systematically replaced one file after the other in my actual test profile with the equivalent file from the latest backup of this profile and restarted TB. I began with the prefs.js file, my usual suspect, but no joy. Finally I came to replace the permissions.sqlite file and ...... bingo! On restart the folder names would be localized correctly again in the GUI language I had chosen before!! I'm no programmer and don't understand which possible role a file such as permissions.sqlite would play as a trigger for the non-localization of the folder names. But for the meantime I have at least a workaround for this issue: replace the permissions.sqlite file or simply delete it. If someone is interested and would like to take an insight: I am keeping two of those "corrupt" permissions.sqlite files at your disposal. And I'm sure there will be more of these corrupt files in the future. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/17 ------------------------------------------------------------------------ On 2019-09-12T07:03:53+00:00 Mozilla wrote: I'm having the same issue while for me I never saw the folder names correctly translated. So I also cannot tell if restoring some permissions.sqlite is helping my case. All language is totally fine besides the default folder names. Talking here about en-US builds with installed langpacks. In my case tested with DE. Also checked that the langpack contains ./chrome/de/locale/de/messenger/messenger.properties:inboxFolderName=Posteingang No matter what I set as intl.multilingual.enabled and intl.locale.requested Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/18 ------------------------------------------------------------------------ On 2019-09-12T18:02:13+00:00 Fkrueger-6 wrote: I can confirm that renaming/removing of permissions.sqlite solves the issue, i.e., the folder names are localized correctly. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/19 ------------------------------------------------------------------------ On 2019-09-13T17:55:05+00:00 Fkrueger-6 wrote: (In reply to FK from comment #19) > I can confirm that renaming/removing of permissions.sqlite solves the issue, > i.e., the folder names are localized correctly. Updating to Thunderbird 68.1.0 the issue is unfortunately back. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/20 ------------------------------------------------------------------------ On 2019-09-15T17:45:14+00:00 Fkrueger-6 wrote: (In reply to Frank K from comment #20) > (In reply to FK from comment #19) > > I can confirm that renaming/removing of permissions.sqlite solves the > > issue, i.e., the folder names are localized correctly. > Updating to Thunderbird 68.1.0 the issue is unfortunately back. FYI: permissions.sqlite is not corrupted for me, i.e. "pragma integrity_check" does not return any error. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/21 ------------------------------------------------------------------------ On 2019-09-16T09:25:28+00:00 De-berberich wrote: It just happened again (still French TB 68.1.0 version with en-US.xpi and de.xpi langpacks in same profile) : I added a new "allow remote content from ....." exception for an A.I. newsletter, went to Preferences (Options) > Advanced > General > Language, switched from English (United States) to German and restarted TB. All folder names were in French instead of German. This time I edited the permissions.sqlite file in a text editor, removed the two lines which had been added by the A.I. newsletter and started TB again: my manual repair of the file must have been effective since now the folders were again correctly localized in German! Unfortunately I'm no sqlite file specialist and I still don't understand in which way permissions.sqlite would interfere in localization of the folder names. In a further experiment I switched language to French and restarted TB in French, set again the "allow remote content from ....." exception for the same A.I. newsletter, then switched to German before restarting TB. This time the folders names were correctly localized in German! When I looked up the contents of the permissions.sqlite file I remarked that this time the new exception for this newsletter had been added at the end of the file whereas the first time it had been added at the top of the file. Does that ring any bells? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/22 ------------------------------------------------------------------------ On 2019-09-25T09:39:24+00:00 Vseerror wrote: >From bug 1579747 comment 32 "It seems that giving read-only permissions to >permissions.sqlite is a temporary workaround solution: chmod -w permissions.sqlite" Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/23 ------------------------------------------------------------------------ On 2019-10-10T21:08:38+00:00 Fkrueger-6 wrote: Apart from the above-mentioned dirty workaround, is there any news regarding a fix? The issue still exists for TB 68.1.1. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/24 ------------------------------------------------------------------------ On 2019-10-10T21:19:27+00:00 Jorg K wrote: Sadly none of this makes any sense. permissions.sqlite is a binary database file, it makes no sense to open it with a text editor. If you do, you see "SQLite format 3" followed by non-printable characters. Which platforms are affected? Linux and Mac? Any case on Windows? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/25 ------------------------------------------------------------------------ On 2019-10-10T21:33:41+00:00 Fkrueger-6 wrote: (In reply to Jorg K (GMT+2) from comment #25) > Sadly none of this makes any sense. permissions.sqlite is a binary database > file, it makes no sense to open it with a text editor. If you do, you see > "SQLite format 3" followed by non-printable characters. I agree. As I have already mentioned in comment #21, permissions.sqlite is not corrupted for me, i.e. "pragma integrity_check" does not return any error. > Which platforms are affected? Linux and Mac? Any case on Windows? I am on Linux (openSUSE TW20191007), Manjaro also seems to be affected (cf. https://forum.manjaro.org/t/thunderbird-68-in-frenglish/102907). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/26 ------------------------------------------------------------------------ On 2019-10-10T21:38:53+00:00 Jorg K wrote: Wow, this is incredible. On Windows with my official 68.1.2 64bit installation I downloaded a Spanish language pack from here http://ftp.mozilla.org/pub/thunderbird/releases/68.1.2/win64/xpi/, installed it and enabled Spanish in the advances settings. I restarted. Everything was Spanish apart from the folder names. Then I made permissions.sqlite read-only in Windows, restarted, now the folder names were in Spanish. I made the file writeable again, restarted and now the folder names are back to English. That's totally crazy. OK, so let's find the regression for this, if we can: Alice, this is going to be difficult. You to know that you can switch languages in the Advanced Settings under Languages if you have pref intl.multilingual.enabled set to true and extensions.langpacks.signatures set to false. For Dailies, you can find the language packs here, for example: http://ftp.mozilla.org/pub/thunderbird/nightly/2019/06/2019-06-29-08-44-29-comm-central-l10n/win64/xpi/ Zibi and Francesco: Why would the localisation of folder names, retrieved from a string bundle here: https://searchfox.org/comm-central/rev/29706036071c4629c2b44512d1acecb64008cc46/mailnews/base/util/nsMsgDBFolder.cpp#2737 have anything to do with permissions.sqlite. Any idea? Oops, Zibi has requests blocked :-( Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/27 ------------------------------------------------------------------------ On 2019-10-10T21:52:07+00:00 Fkrueger-6 wrote: (In reply to Jorg K (GMT+2) from comment #27) > Wow, this is incredible. On Windows with my official 68.1.2 64bit > installation I downloaded a Spanish language pack from here > http://ftp.mozilla.org/pub/thunderbird/releases/68.1.2/win64/xpi/, > installed it and enabled Spanish in the advances settings. I restarted. > > Everything was Spanish apart from the folder names. Then I made > permissions.sqlite read-only in Windows, restarted, now the folder names were > in Spanish. I made the file writeable again, restarted and now the folder > names are back to English. That's totally crazy. Incidentally, renaming/removing permissions.sqlite gives the same result. That is very weird indeed. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/28 ------------------------------------------------------------------------ On 2019-10-10T22:02:15+00:00 Jorg K wrote: Or maybe we should ask Axel. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/29 ------------------------------------------------------------------------ On 2019-10-10T22:07:36+00:00 Alice0775-t wrote: (In reply to Jorg K (GMT+2) from comment #27) > Alice, this is going to be difficult. You to know that you can switch > languages in the Advanced Settings under Languages if you have pref > intl.multilingual.enabled set to true and extensions.langpacks.signatures set > to false. > > For Dailies, you can find the language packs here, for example: > http://ftp.mozilla.org/pub/thunderbird/nightly/2019/06/2019-06-29-08-44-29-comm-central-l10n/win64/xpi/ As far as I know, folder names of imap(gmail) and local are not changed between en-US and ja build. I do not know about lang pack. I have never used lang pack, because the lang pack is version sensitive. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/30 ------------------------------------------------------------------------ On 2019-10-10T22:15:12+00:00 Jorg K wrote: Well, a language pack is like an add-on, you need to download and install it. Then you can select the newly installed version in the Advanced Settings under Languages. Yes, they are version dependent, that's why finding the regression here is tricky. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/31 ------------------------------------------------------------------------ On 2019-10-10T22:33:13+00:00 Jorg K wrote: OK, here's more weirdness. I've opened permissions.sqlite with my trusty "DB Browser for SQLite" on windows and looked at the two tables it has. moz_hosts aren't interesting, but I deleted all records anyway. No change. Then I ran this SQL on the other table: `delete from moz_perms where type = 'storageAccessAPI'` I have no idea what those storage permissions are, so I blew them all away. ... And, dada, now the folders are in Spanish. So now we need to understand what that's about. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/32 ------------------------------------------------------------------------ On 2019-10-10T22:47:56+00:00 Alice0775-t wrote: intl.multilingual.enabled set to true, install lang pack, options>Advanced>General>Language > select a lang & restart TB 68.1.2(en-US build) + Japanese Language Pack68.0buildid20190909201201 : works for me(except imap/local folder). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/33 ------------------------------------------------------------------------ On 2019-10-10T22:51:47+00:00 Jorg K wrote: Right. The folders should also be translated like in the localised Japanese version. So the question it: When did that break? So when did en-US + Japanese language pack not give any Japanese folder names any more. Check my comment #32: It has something to do with the rows of type storageAccessAPI in table moz_perms of that database. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/34 ------------------------------------------------------------------------ On 2019-10-10T22:58:37+00:00 Jorg K wrote: *** Bug 1580110 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/35 ------------------------------------------------------------------------ On 2019-10-10T22:58:58+00:00 Jorg K wrote: *** Bug 1581124 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/36 ------------------------------------------------------------------------ On 2019-10-10T22:59:17+00:00 Jorg K wrote: *** Bug 1581288 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/37 ------------------------------------------------------------------------ On 2019-10-10T23:09:15+00:00 Jorg K wrote: Ehsan, looks like you worked on most of the code in the vicinity of `storageAccessAPI`. We're seeing records like this "7758" "mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/Local%20Folders/Mozilla?number=141800" "storageAccessAPI" "1" "2" "1570788430711" "1568196430711" in permissions.sqlite. Blowing all the records with type storageAccessAPI away fixes the bug of Thunderbird folder names not being localised under some circumstances. That's about the weirdest bug I've ever seen. You can also remove permissions.sqlite or make it read-only to achieve the same effect. Can you shine some light onto this? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/38 ------------------------------------------------------------------------ On 2019-10-10T23:10:14+00:00 Alice0775-t wrote: (In reply to Jorg K (GMT+2) from comment #34) > So the question it: When did that break? I do not understand what is problem. Do you mean about folder names of imap? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/39 ------------------------------------------------------------------------ On 2019-10-10T23:17:12+00:00 Jorg K wrote: IMAP and local folders. Check attachment 9092662, everything French, but the folders are English. If you download a Japanese version of TB, you get the folders in Japanese, right? When you install en-US + Japanese language pack, you get the folders in English under some circumstances. That's incorrect. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/40 ------------------------------------------------------------------------ On 2019-10-10T23:22:47+00:00 L10n-mozilla wrote: Neither flod nor I can help here a lot. Language packs are interesting, and their behavior is highly sensitive to timing and caching of things. All that timing changes occasionally in the backend, and then you need to figure out your caching and loading order and stuff again. Eventually, we hope to have things in Fluent, and in a way that things update if locale selections change. Things that are not doing that need manual care. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/41 ------------------------------------------------------------------------ On 2019-10-11T02:44:22+00:00 Ehsan-mozilla wrote: (In reply to Jorg K (GMT+2) from comment #38) > Ehsan, looks like you worked on most of the code in the vicinity of > `storageAccessAPI`. We're seeing records like this > "7758" > "mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/Local%20Folders/Mozilla?number=141800" > "storageAccessAPI" "1" "2" "1570788430711" "1568196430711" > in permissions.sqlite. > > Blowing all the records with type storageAccessAPI away fixes the bug of > Thunderbird folder names not being localised under some circumstances. That's > about the weirdest bug I've ever seen. You can also remove permissions.sqlite > or make it read-only to achieve the same effect. > > Can you shine some light onto this? These permissions are used to store information about which sites the user interacts with. They're saved through `AntiTrackingCommon::StoreUserInteractionFor()` and later on can be checked using `AntiTrackingCommon::HasUserInteraction()`. Of course none of this is for the usage of Thunderbird and it looks like some code in Thunderbird is coming across Gecko's anti-tracking code in an unexpected way and things are going haywire. I have no theories that explain the behaviour you're seeing unfortunately and cannot think of why the existence of these permissions should matter... The only code that we have that uses `HasUserInteraction()` shouldn't really ever be called on Thunderbird, so whether or not these permissions exist shouldn't change the behaviour of the code that uses them. What else it changes elsewhere, I'm not sure. The only thing that occurs to me is perhaps some code is enumerating permissions, looking at their types and failing to handle `storageAccessAPI` or something like that. You can check for those types of possibilities by going through the `nsIPermissionManager` APIs and for those who could possibly give out information about these permissions add `printf` debugging code maybe? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/42 ------------------------------------------------------------------------ On 2019-10-11T06:56:45+00:00 Jorg K wrote: Thanks for the comment, Ehsan. We don't do a whole lot with permissions in C-C, we mostly add and test permissions of type "image" for embedded images: https://searchfox.org/comm-central/search?q=nsIPermissionManager&case=false®exp=false&path=mail https://searchfox.org/comm-central/search?q=addPermission&case=false®exp=false&path=mail https://searchfox.org/comm-central/search?q=testPermission&case=false®exp=false&path=mail We don't use the enumerator-style functions getAllForPrincipal, getAllWithTypePrefix or "readonly attribute nsISimpleEnumerator enumerator". I'll add some prints to see why AntiTrackingCommon::StoreUserInteractionFor() is called for those mailbox: URLs you can see in comment #42. I'll also see where AntiTrackingCommon::HasUserInteraction() is called in TB. The good thing is that the problem is reproducible in a local trunk build using the "faulty" permissions.sqlite from my production profile. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/43 ------------------------------------------------------------------------ On 2019-10-11T07:59:43+00:00 Jorg K wrote: OK, I added some debug. Just starting TB, I see no calls to HasUserInteraction and three calls to StoreUserInteractionFor with a null URI: === StoreUserInteractionFor called with null URI from this debug: ``` void AntiTrackingCommon::StoreUserInteractionFor(nsIPrincipal* aPrincipal) { if (XRE_IsParentProcess()) { nsCOMPtr<nsIURI> uri; Unused << aPrincipal->GetURI(getter_AddRefs(uri)); LOG_SPEC(("Saving the userInteraction for %s", _spec), uri); if (uri) { nsAutoCString s; uri->GetSpec(s); printf("=== StoreUserInteractionFor |%s|\n", s.get()); } else { printf("=== StoreUserInteractionFor called with null URI\n"); } ``` I wasn't able to attach the debugger early enough during startup, but when I click onto a folder in the TB folder tree, I also get a "StoreUserInteractionFor called with null URI" coming from this stack: ``` xul.dll!mozilla::AntiTrackingCommon::StoreUserInteractionFor(nsIPrincipal * aPrincipal) Line 2135 C++ xul.dll!mozilla::dom::Document::SetUserHasInteracted() Line 14958 C++ xul.dll!mozilla::EventStateManager::PreHandleEvent(nsPresContext * aPresContext, mozilla::WidgetEvent * aEvent, nsIFrame * aTargetFrame, nsIContent * aTargetContent, nsEventStatus * aStatus, nsIContent * aOverrideClickTarget) Line 511 C++ xul.dll!mozilla::PresShell::EventHandler::DispatchEvent(mozilla::EventStateManager * aEventStateManager, mozilla::WidgetEvent * aEvent, bool aEventStatus, nsEventStatus * aOverrideClickTarget, nsIContent *) Line 7798 C++ xul.dll!mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(mozilla::WidgetEvent * aEvent, nsEventStatus * aEventStatus, bool aOverrideClickTarget, nsIContent *) Line 7770 C++ xul.dll!mozilla::PresShell::EventHandler::HandleEventWithTarget(mozilla::WidgetEvent * aEvent, nsIFrame * aNewEventFrame, nsIContent * aNewEventContent, nsEventStatus * aEventStatus, bool aIsHandlingNativeEvent, nsIContent * * aTargetContent, nsIContent * aOverrideClickTarget) Line 7654 C++ xul.dll!mozilla::PointerEventHandler::DispatchPointerFromMouseOrTouch(mozilla::PresShell * aShell, nsIFrame * aFrame, nsIContent * aContent, mozilla::WidgetGUIEvent * aEvent, bool aStatus, nsEventStatus * aTargetContent, nsIContent * *) Line 536 C++ xul.dll!mozilla::PresShell::EventHandler::DispatchPrecedingPointerEvent(nsIFrame * aFrameForPresShell, mozilla::WidgetGUIEvent * aGUIEvent, nsIContent * aPointerCapturingContent, bool aEventTargetData, mozilla::PresShell::EventHandler::EventTargetData * aEventStatus, nsEventStatus *) Line 6880 C++ xul.dll!mozilla::PresShell::EventHandler::HandleEventUsingCoordinates(nsIFrame * aFrameForPresShell, mozilla::WidgetGUIEvent * aGUIEvent, nsEventStatus * aEventStatus, bool) Line 6705 C++ xul.dll!mozilla::PresShell::EventHandler::HandleEvent(nsIFrame * aFrameForPresShell, mozilla::WidgetGUIEvent * aGUIEvent, bool aEventStatus, nsEventStatus *) Line 6531 C++ xul.dll!mozilla::PresShell::HandleEvent(nsIFrame * aFrameForPresShell, mozilla::WidgetGUIEvent * aGUIEvent, bool aEventStatus, nsEventStatus *) Line 6457 C++ ``` Something wrong with the interaction of the clang-cl compiler and the VS debugger on Windows since it doesn't show MaybeStoreUserInteractionAsPermission() on the stack at that point, but I guess the call comes from here: https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/dom/base/Document.cpp#15264 It's all a mystery to me since all this runs whether or not permissions.sqlite is in place. Observed behaviour: With the faulty permissions.sqlite in place the folder names are not localised, deleting the faulty permissions.sqlite makes them localised. I tried ``` void Document::MaybeStoreUserInteractionAsPermission() { return; ``` but that doesn't fix the issue either. So where from here? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/44 ------------------------------------------------------------------------ On 2019-10-11T08:11:44+00:00 Jorg K wrote: ~~We could be barking up the wrong tree here. Maybe those 2400+ storageAccessAPI records are triggering a storage bug?~~ No, see next comment. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/45 ------------------------------------------------------------------------ On 2019-10-11T09:05:48+00:00 Jorg K wrote: OK, only removing IMAP entries also fixes the issue: delete from moz_perms where type = 'storageAccessAPI' and origin like 'imap%' Here's an IMAP entry: "8574" "8574" "imap://info%40hostalpancheta%2...@mail.hostalpancheta.es:993/fetch%3EUID%3E.INBOX.Trash%3E7520" "storageAccessAPI" "1" "2" "1571733595886" "1569141595886" In fact, I deleted all records from moz_perms except one IMAP record, and that reproduces the problem. So it looks like that IMAP origin causes a big issue. Changing imap to bimap in that record makes the issue go away. So somehow IMAP must reach into that DB, and get confused. Maybe we do use "readonly attribute nsISimpleEnumerator enumerator" for nsIPermissionManager in IMAP, hard to tell, there is some messing with permissions: https://searchfox.org/comm-central/search?q=permission&case=false®exp=false&path=imap ... and I have to leave right now. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/46 ------------------------------------------------------------------------ On 2019-10-11T10:07:40+00:00 Jorg K wrote: OK, current working assumption: Something goes wrong when messing around with permissions during start-up, so we error out before reaching the code that gets the localised folder names. I'd have to add some debug/breakpoint to nsPermissionManager::GetEnumerator(). I'm leaving the NI for Ehsan so he can look at comment #44 to see whether it makes sense to call StoreUserInteractionFor() with a principal that has no URI. Alice, thanks for looking into the issue. I guess we'll solve it with debugging and a regression range is not necessary. Most likely it broke when storageAccessAPI was introduced as a type into the permissions manager. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/47 ------------------------------------------------------------------------ On 2019-10-11T17:49:43+00:00 Ehsan-mozilla wrote: (In reply to Jorg K (GMT+2) from comment #47) > I'm leaving the NI for Ehsan so he can look at comment #44 to see whether it > makes sense to call StoreUserInteractionFor() with a principal that has no > URI. Sure. The permission manager doesn't care about the URI for the principal, it uses the origin of the principal to store the permission, and as you can see in the dump of the sqlite file, the permissions are stored successfully. As to your higher level question on whether this *makes sense*, in my opinion, no it doesn't make sense for principals representing `imap`/`mailbox`/or any other non-web URIs to have an *origin*, since origin is a *Web* concept defined in [HTML](https://html.spec.whatwg.org/multipage/origin.html#origin). Generally when Gecko encounters non-Web things pretending to be origins, I personally wouldn't expect the resulting behaviour to make sense. I think I brought up this point recently in another bug where we were setting cookies on either `imap` or `mailbox` URIs... But anyway, I don't think going down the path of figuring out this philosophical question would be particularly helpful to answer the question of why things fail with the presence of this permission. You still need to find the code in Thunderbird which is accessing the permission manager and finding something it doesn't expect to see how to fix this, I think. If you found it super hard to find this code, perhaps it would help to add debugging code to `nsPermissionManager::GetPermissionHashKey()` and also `GetPrincipalFromOrigin()` which are the core functions that are called when we're about to look up a permission or enumerate them. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/49 ------------------------------------------------------------------------ On 2019-10-11T20:34:02+00:00 Jorg K wrote: > ... and as you can see in the dump of the sqlite file, the permissions are stored successfully. Well, getting the origin from the principal I see this: === StoreUserInteractionFor |[System Principal]| But yes, also see: === StoreUserInteractionFor |mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/Local%20Folders/Jan%2018?number=9| > You still need to find the code in Thunderbird which is accessing the permission manager and finding something it doesn't expect to see how to fix this, I think. Indeed. I'll tackle this in the next few days, it's getting late in Europe on a Friday night. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/50 ------------------------------------------------------------------------ On 2019-10-11T22:38:05+00:00 Jorg K wrote: OK, I've dug some more. With a Spanish language pack installed, if permissions.sqlite contains an imap record, then `GetStringFromName("inboxFolderName", kLocalizedInboxName);` returns "Inbox", with no permissions.sqlite (or no imap record) it returns "Bandeja de entrada". So this seems to a Mozilla platform bug, somehow there must be a connection between L10N and the content of the permissions database. The calls were looking for won't be found in C-C code but in M-C code. So this code https://searchfox.org/comm-central/rev/29706036071c4629c2b44512d1acecb64008cc46/mailnews/base/util/nsMsgDBFolder.cpp#2737 always runs, but the result differs depending on content of permissions.sqlite. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/51 ------------------------------------------------------------------------ On 2019-10-13T13:59:16+00:00 Jorg K wrote: (In reply to Jorg K (GMT+2) from comment #50) > OK, I've dug some more. With a Spanish language pack installed, if > permissions.sqlite contains an imap record, then > `GetStringFromName("inboxFolderName", kLocalizedInboxName);` returns "Inbox", > with no permissions.sqlite (or no imap record) it returns "Bandeja de > entrada". So one could assume that GetStringFromName doesn't work, but that's not the case. The string accountDisconnected is only retrieved via GetStringFromName https://searchfox.org/comm-central/search?q=accountDisconnected&case=false®exp=false&path= and that is translated properly. Of course it sits in a different bundle, conversations.properties, whereas the untranslated folder names are in messenger.properties. So I tried a string from that bundle, LoadingMailMsgForPrint, and that is also translated. So its just the folder names. So weird. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/54 ------------------------------------------------------------------------ On 2019-10-13T14:27:51+00:00 Jorg K wrote: Did some more digging. In the bad case, the folder name strings are about the first strings to be retrieved: Line 139: === GetStringFromName(inboxFolderName) = |Inbox| (0) Line 141: === GetStringFromName(trashFolderName) = |Trash| (0) Line 142: === GetStringFromName(sentFolderName) = |Sent| (0) Line 143: === GetStringFromName(draftsFolderName) = |Drafts| (0) Line 144: === GetStringFromName(templatesFolderName) = |Templates| (0) Line 145: === GetStringFromName(junkFolderName) = |Junk| (0) Line 146: === GetStringFromName(outboxFolderName) = |Outbox| (0) Line 147: === GetStringFromName(archivesFolderName) = |Archives| (0) Line 148: === GetStringFromName(brandShortName) = |Daily| (0) Line 149: === GetStringFromName(mailnews.view_default_charset) = |ISO-8859-1| (0) Line 159: === GetStringFromName(openH264_name) = |OpenH264 Video Codec proporcionado por C Line 161: === GetStringFromName(openH264_description2) = |Este plugin se ha instalado auto and after that, it those folder name strings, strings come out in Spanish. In the good case, the plugin related strings are retrieved first: Line 106: === GetStringFromName(brandShortName) = |Daily| (0) Line 129: === GetStringFromName(openH264_name) = |OpenH264 Video Codec proporcionado por C Line 131: === GetStringFromName(openH264_description2) = |Este plugin se ha instalado auto Line 136: === GetStringFromName(widevine_description) = |MA3dulo de descifrado de contenid Line 138: === GetStringFromName(cdm_description2) = |Este complemento permite la reproducc Line 162: === GetStringFromName(inboxFolderName) = |Bandeja de entrada| (0) Line 164: === GetStringFromName(trashFolderName) = |Papelera| (0) Line 165: === GetStringFromName(sentFolderName) = |Enviados| (0) Line 166: === GetStringFromName(draftsFolderName) = |Borradores| (0) Line 167: === GetStringFromName(templatesFolderName) = |Plantillas| (0) Line 168: === GetStringFromName(junkFolderName) = |Correo no deseado| (0) Line 169: === GetStringFromName(outboxFolderName) = |Bandeja de salida| (0) Line 170: === GetStringFromName(archivesFolderName) = |Archivos| (0) So there is some timing issue in loading the language pack. Quoting Axel from comment #41: > Language packs are interesting, and their behavior is highly sensitive to > timing and caching of things. All that timing changes occasionally in the > backend, and then you need to figure out your caching and loading order and > stuff again. So I think that's what happens. It's still curious that it depends on the content of the permissions.sqlite database. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/55 ------------------------------------------------------------------------ On 2019-10-13T15:28:55+00:00 Jorg K wrote: OK, I think I've tracked it down. When permissions.sqlite is imported, it runs GetPrincipalFromOrigin() on the imap origin/URL that is stored in the database: https://searchfox.org/mozilla-central/rev/e54b007827800410a616ce0584ccaae308a4afd9/extensions/permissions/nsPermissionManager.cpp#2832 That in the calls NS_NewURI() for an imap origin and that runs a lot of IMAP code (we know that imap: URL creation runs an awful lot of code), including retrieving the localised folder names, before the localised string bundle is even loaded. That's it. No imap: URL in the database, no problem. I'm going to propose a patch to skip MailNews URLs on import. Let's see what Ehsan thinks. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/56 ------------------------------------------------------------------------ On 2019-10-13T16:08:48+00:00 Jorg K wrote: Created attachment 9100750 permissions.sqlite Here is the permissions.sqlite database the reviewer can use for testing. He can also install a German language pack from here: http://ftp.mozilla.org/pub/thunderbird/nightly/2019/10/2019-10-13-07-58-41-comm-central-l10n/linux-x86_64/xpi/ Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/57 ------------------------------------------------------------------------ On 2019-10-13T16:19:59+00:00 Jorg K wrote: Created attachment 9100751 1575512-jit-strings.patch - Working, but not desirable I tried to do a C-C-only solution by initialising the strings only when needed, but it turns out that that also doesn't work. This patch here gets the strings all the time before they are used and that guarantees localised results. The only other solution would be to teach M-C about MailNews URLs and then skip those upon import, see comment #53. Oh, I just had another idea. The permissions manager only worries about http(s) and ftp, so let me do an M-C patch for that. Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/58 ------------------------------------------------------------------------ On 2019-10-13T16:35:46+00:00 Jorg K wrote: Created attachment 9100752 Bug 1575512 - Skip MailNews URLs on permissions import to avoid timing issue with string bundles. r=ehsan Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/59 ------------------------------------------------------------------------ On 2019-10-13T19:30:37+00:00 Jorg K wrote: OK, let's the summarise the issue again: When the permissions are read from permissions.sqlite at start-up, URIs are created from the stored origins. Creating an imap: URI runs a whole lot of MailNews code, which also reads localised names of the standard folder names into static variables. Sadly that happens at the time where l10n is not initialised yet, so users see the untranslated names later. Possible solutions: 1) When reading permissions.sqlite, only import http(s), ftp (and sadly chrome) origins (attachment in Phab) 2) Always translate strings when needed, don't pre-cache them during start-up (attachment 9100751) 3) Hacky and nonsense: Only lookup the strings 50 times. That's an empirical value. After 20 lookups there were still not translated, after 50 lookups they were (attachment 9100764). Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/60 ------------------------------------------------------------------------ On 2019-10-13T19:31:01+00:00 Jorg K wrote: Created attachment 9100764 1575512-jit-strings.patch - Working, but totally silly Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/61 ------------------------------------------------------------------------ On 2019-10-15T17:00:13+00:00 Jorg K wrote: 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"*. 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 ;-) 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. 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 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847772/comments/62 ** Changed in: thunderbird Status: Unknown => In Progress ** Changed in: thunderbird Importance: Unknown => Medium -- 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
