"Print to File" does not create the expected file in non-English locales
"Print to file" works as expected in en_US locales, but on Tails and current Debian unstable with French locales, the expected file is not created although the GUI feedback looks like everything went just fine; reproduced both with the en_US and French version of Tor Browser, so this seems to depend on the locales only.
Activity
added AffectsTails in Legacy / Trac TorBrowserTeam201712R in Legacy / Trac component::applications/tor browser in Legacy / Trac owner::pospeselr in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-7.0-issues in Legacy / Trac tbb-e10s in Legacy / Trac tbb-no-uplift in Legacy / Trac tbb-regression in Legacy / Trac type::defect in Legacy / Trac labels
Replying to intrigeri:
This feels like basic functionality to me, but I understand that the TBB team has probably higher priority items on their plate. Fine :)
Indeed we have a sponsor deadline in a couple of weeks and most of us are picking items so we meet that one.
Any hint you folks can share, in case I want to look deeper myself?
Are you sure this is a non-en-US-issue? It seems that printing to a file does not work with en-US bundles either for me on Linux. That said does it start working if you disable multiprocess mode by flipping
browser.tabs.remote.autostart.2? (It does for me)Given that it seems to be a multiprocess issue then this might be a good ticket for Richard to work on to get more familiar with another important browser concept and related bugs/issues. (And he is not as bound to the sponsor deadline as other folks from the team)
Richard: Do you think you could put that one onto your plate?
Trac:
Status: new to needs_information
Keywords: N/A deleted, tbb-e10s added
Cc: intrigeri to intrigeri, pospeselr-
For me any page is sufficient. Take for example
about:tor. Here is what I did (with an en-US bundle):- I opened the hamburger menu in the upper right corner and selected the Print icon.
- I clicked on the Print... button, selected Print to File, chose a name and clicked on Print.
- I repeated 2) but no warning dialog appeared (notifying you that you are about to overwrite a file).
- Upon looking in the directory where the file was supposed to be saved it turns out it was not.
- Repeating 1) and 2) with multiprocess mode disabled solves it for me.
So those repro steps result in successful printing for me
- Debian Unstable VM (1 core CPU, 4 gigs of RAM, 8 GB disk)
- latest Tor-Browser (version 7.0.5)
- browser.tabs.remote.autostart.2 = true
- printing various pages (about:config, slashdot, reddit, etc)
gk: could you perhaps post Tor Browser's debug log output on a failed print?
-
Replying to pospeselr:
So those repro steps result in successful printing for me
- Debian Unstable VM (1 core CPU, 4 gigs of RAM, 8 GB disk)
- latest Tor-Browser (version 7.0.5)
- browser.tabs.remote.autostart.2 = true
- printing various pages (about:config, slashdot, reddit, etc)
gk: could you perhaps post Tor Browser's debug log output on a failed print?
There is not shown much, only
(firefox:3965): GLib-GObject-WARNING **: ../../../../gobject/gsignal.c:3492: signal name 'load_complete' is invalid for instance '0x7f72016908d0' of type 'MaiAtkType139'but I am not convinced that this indicates what is going on.
That said, you could check if you can reproduce it with Tails. I am wondering, though, what's different on my and Tails' Linux config. I took a vanilla Ubuntu 14.04 which I had on a different machine and I had not issues.
intrigeri: do you have any ideas?
Trac:
Status: assigned to needs_information -
Ok, so I've gotten some similar behaviour as expressed in this bug. In latest Tails when attempting to save to the tor-browser folder ( /usr/local/lib/tor-browser ) the print to file functionality seems to fail silently, which makes sense as the amnesia user doesn't have write permissions there. However, the UI does not provide any indication of file write failure. As expected, the multiprocessing option also has no effect in this scenario.
Does this error happen for y'all on 64 or 32-bit? I've been doing all my testing on 64-bit so far.
-
Replying to pospeselr:
Ok, so I've gotten some similar behaviour as expressed in this bug. In latest Tails when attempting to save to the tor-browser folder ( /usr/local/lib/tor-browser ) the print to file functionality seems to fail silently, which makes sense as the amnesia user doesn't have write permissions there. However, the UI does not provide any indication of file write failure. As expected, the multiprocessing option also has no effect in this scenario.
What happens if you choose a writable path?
Does this error happen for y'all on 64 or 32-bit? I've been doing all my testing on 64-bit so far.
64-bit.
-
Replying to gk:
Replying to pospeselr:
Ok, so I've gotten some similar behaviour as expressed in this bug. In latest Tails when attempting to save to the tor-browser folder ( /usr/local/lib/tor-browser ) the print to file functionality seems to fail silently, which makes sense as the amnesia user doesn't have write permissions there. However, the UI does not provide any indication of file write failure. As expected, the multiprocessing option also has no effect in this scenario.
What happens if you choose a writable path?
Does this error happen for y'all on 64 or 32-bit? I've been doing all my testing on 64-bit so far.
64-bit.
So, interestingly enough on Tails Tor Browser (version 7.0.6) only seems to be able to write to /home/amnesia/Tor\ Browser. Other valid paths (~, ~/Documents, ~/media/amnesia/Disk) are not writable and any attempt to do so fails silently (including saving an image, saving a web-page, printing). File browser also refuses to even read contents of any folder except for /home/amnesia/Tor\ Browser and Tor Browser's installation directory.
The browser.tabs.remote.autostart.2 has no effect one way or the other.
Tor Browser (version 7.0.6) does not exhibit this behaviour on my local install (Ubuntu 17.04), ie I can pretty much read/write anywhere that's consistent with folder permissions. Is Tor Browser in Tails more restricted somehow?
-
Replying to pospeselr:
Replying to gk:
Replying to pospeselr:
Ok, so I've gotten some similar behaviour as expressed in this bug. In latest Tails when attempting to save to the tor-browser folder ( /usr/local/lib/tor-browser ) the print to file functionality seems to fail silently, which makes sense as the amnesia user doesn't have write permissions there. However, the UI does not provide any indication of file write failure. As expected, the multiprocessing option also has no effect in this scenario.
What happens if you choose a writable path?
Does this error happen for y'all on 64 or 32-bit? I've been doing all my testing on 64-bit so far.
64-bit.
So, interestingly enough on Tails Tor Browser (version 7.0.6) only seems to be able to write to /home/amnesia/Tor\ Browser. Other valid paths (~, ~/Documents, ~/media/amnesia/Disk) are not writable and any attempt to do so fails silently (including saving an image, saving a web-page, printing). File browser also refuses to even read contents of any folder except for /home/amnesia/Tor\ Browser and Tor Browser's installation directory.
The browser.tabs.remote.autostart.2 has no effect one way or the other.
Tor Browser (version 7.0.6) does not exhibit this behaviour on my local install (Ubuntu 17.04), ie I can pretty much read/write anywhere that's consistent with folder permissions. Is Tor Browser in Tails more restricted somehow?
Yes, I think so. Did you get anything printed to /home/amnesia/Tor\ Browser? If so, is it working with, say, Tails in French as well?
Replying to gk:
For me any page is sufficient. Take for example
about:tor. Here is what I did (with an en-US bundle):- I opened the hamburger menu in the upper right corner and selected the Print icon.
- I clicked on the Print... button, selected Print to File, chose a name and clicked on Print.
- I repeated 2) but no warning dialog appeared (notifying you that you are about to overwrite a file).
- Upon looking in the directory where the file was supposed to be saved it turns out it was not.
- Repeating 1) and 2) with multiprocess mode disabled solves it for me.
I've tested again with AppArmor fully disabled (removed
security=apparmor apparmor=1from the kernel command line) to make sure it's not involved. I see the same in Tails 3.2 started in French, but if started with the default locale (en_US) 1) and 2) work fine even without disabling multiprocess.-
Replying to intrigeri:
Replying to gk: I've tested again with AppArmor fully disabled (removed
security=apparmor apparmor=1from the kernel command line) to make sure it's not involved. I see the same in Tails 3.2 started in French, but if started with the default locale (en_US) 1) and 2) work fine even without disabling multiprocess.Same on current Debian sid (I've left AppArmor enabled though since my previous tests seem to remove it from the list of candidate culprits).
-
Replying to intrigeri:
Replying to intrigeri:
Replying to gk: I've tested again with AppArmor fully disabled (removed
security=apparmor apparmor=1from the kernel command line) to make sure it's not involved. I see the same in Tails 3.2 started in French, but if started with the default locale (en_US) 1) and 2) work fine even without disabling multiprocess.Same on current Debian sid (I've left AppArmor enabled though since my previous tests seem to remove it from the list of candidate culprits).
In comment:13 Richard mentioned he used a Debian unstable to test. I wonder if you could give some STR for the getting the Debian sid you used because I wonder what the essential difference between your (and probably mine) and Richard's test setup is.
-
I've installed Buster a few weeks ago (using debian-live-buster-DI-a1-amd64-gnome.iso), then upgraded to sid and kept the system up-to-date. FWIW the GNOME session on current Debian testing/sid defaults to Wayland. Then to reproduce this bug I've
dpkg-reconfigure locales, enabled fr_FR.UTF-8, picked French language + format in GNOME's user settings, restarted the GNOME session, used torbrowser-launcher to download & unpack Tor Browser, started Tor Browser via the GNOME Overview (i.e. the system-wide.desktop file installed by torbrowser-launcher) and boom. I'm running the 4.13.2-1~exp1 kernel from Debian experimental but it shouldn't matter.I've reproduced this again with
~/.local/share/torbrowser/tbb/x86_64/tor-browser_fr/start-tor-browser.desktopi.e. bypassing torbrowser-launcher. Same with~/.local/share/torbrowser/tbb/x86_64/tor-browser_fr/Browser/start-tor-browser --verbose.I've tried
apt install cupsbut it did not help.Then I wanted to ensure torbrowser-launcher does not mess up things so I've unpacked tor-browser-linux64-7.0.6_fr.tar.xz myself, cd'ed into the extracted directory and
./start-tor-browser.desktop. Same problem again.I see no relevant error message in the terminal (with
--verbose) nor in the browser console. Any additional debugging info I could share? -
Well good news is that for whatever reason on my laptop 'Print to File' does not work with latest Tor Browser built from source. However the javascript.use_us_english_locale option seems to have no effect (and neither does the browser.tabs.remote.autostart.2 option). Will dig into this tomorrow and try and find some idea of what's going on.
-
Replying to gk:
Does the problem go away if you flip
javascript.use_us_english_localetofalse?Yes! (On Tails 3.2)
-
So I've recreated intrigeri's setup mentioned above in a VM: debian, reconfigured to fr_FR, and using stock 7.0.6 French Tor Browser and I am seeing print errors, though not in the way described :(
With the above described configuration about:tor always fails to print, while about:support always succeeds. The javascript.use_us_english_locale setting has no effect on the outcome.
Discovered in all this that apparently build we release don't have symbols(?) so haven't had much luck debugging this issue. Simply dropping in a locally built version of Tor Browser on top of the install seems to make the issue go away and behave as expected. Working on building FR sku from scratch via rbm and working from there once I've a build with symbols and source.
-
Ok, some good progress today. A couple things to note: this bug does repro with the javascript.use_us_english_locale setting, but it takes some finagling to get that setting to stick (and regardless of what the real value is, it will always appear as true on browser start). To get it to stick you need to toggle it to false, exit the tab and browser and come back. To toggle it back to true, you have to toggle it twice, exit the tab and browser and come back.
So, the reason this is happening is in part due to localization and multi-process printing. In the multi-process case, the 'Web Content' process has to enumerate the printers for itself to find the target printer the 'firefox' process wants us to print to. To identify said printer, we're doing a string compare on the name of the printers GTK is aware of and continues on with printing once it finds the name provided by the parent 'firefox' process.
The reason why we fail is that with javascript.use_us_english_locale=true is that the firefox process names the 'Print to File' printer as 'Print to File' whereas gtk has a GTKPrinter named (in the French case) 'Imprimer dans un fichier' due to the system's language settings (which explains why this bug does not happen in localized tor-browser on an English system). In order for printing to work, we have to send down the name GTK is expecting.
Knowing all this should be relatively straight-forward to track down where we're not localizing when we should.
EDIT: on a side-note pretty sure this identification scheme is completely broken if a user has 2 printers with identical names added; the child process would always print to first printer with the matching name.
-
Ultimate source of the problem is that nsLocaleService constructor is not honoring the javascript.use_us_english_locale flag. I've a solution in mind, but will have to verify it doesn't break Windows and OSX. Look for a patch tomorrow.
A couple of other places also call setlocale(FOO, "") which sets the process's locale to the system locale, which is subsequently undone by the OverrideDefaultLocaleIfNeeded() function during startup:
- nsNativeCharsetUtils
- XPCOMInit
Another side-note/observation regarding localization: shouldn't we be setting the locale based off of the Tor Browser version (assuming the use_us_english_locale flag is not set) rather than the OS defaults?
-
Verified this patch today against the 52.4.1 stable series. With this patch applied Print to File works as expected when:
- security.sandbox.content.level is reduced from 2 to either 1 or 0
- javascript.use_us_english_locale either enabled or disabled
Issue legacy/trac#23970 (moved) should resolve the sandboxing issues.
Against the 52.4.1 alpha series the patch fails when javascript.use_us_english_locale is 'false'. There appears to be disagreement between the firefox and Web Content processes regarding the value of the javascript.use_us_english_locale setting in this case.
EDIT: patch fails to build on OSX, will fix tomorrow
Trac:
Status: needs_information to needs_review
Keywords: N/A deleted, TorBrowserTeam201711R added -
Okay, it solves the problem for me, nice! Yes, i see the OSX build failure, too. Could you additionally fix your commit message by including the bug number for easy reference and be a bit more verbose in it? Good to know could be which of our patches introduced the bug and what it is we are trying to fix.
Trac:
Keywords: TorBrowserTeam201711R deleted, TorBrowserTeam201711 added
Status: needs_review to needs_revision -
nsLocaleService no longer exists in Firefox ( https://bugzilla.mozilla.org/show_bug.cgi?id=1356263 ) so this change does not need to uplifted. Verified with latest Firefox beta in same Debian VM, Print to File works as expected.
r=brade, r=mcs Good work on this bug. It would be nice to fix the following typos within the commit message: s/base off/based off/ s/prference/preference/ s/setlocale occur/setlocale occurs/
R.e. uplifting to Firefox, I wonder if the new replacement for nsLocaleService has a similar problem. But I guess your testing shows that it does not. Also, we are patching files under xpcom that are still present on mozilla-central today so maybe we want to request that those parts be uplifted? e.g., the changes in xpcom/build/XPCOMInit.cpp may still be needed.
-
The patch good to me and nice work! I fixed the typo's mentioned in comment:34 and some more and committed the patch to
tor-browser-52.5.2esr-7.5-2(commit 8ea98394). Leaving it open for now to address mcs's questions in comment:34. -
The changes in XPCOM do not need to be uplifted (and technically is not required in Tor Browser) since those set_locale calls occur before the final call added by Arthur which checks the use_english_locale pref.
In fact (if I understood comments made by mozilla devs in nsAppRunner.cpp) the issue that check is meant to fix (per OS date formatting) goes away as JavaScript date formatting is no longer supported ( https://bugzilla.mozilla.org/show_bug.cgi?id=818634 ).
mentioned in issue legacy/trac#23970 (moved)
moved from legacy/trac#23016 (moved)
added Bug label and removed 1 deleted label
added Tails label