Opened 7 months ago

Closed 2 months ago

Last modified 4 weeks ago

#23016 closed defect (fixed)

"Print to File" does not create the expected file in non-English locales

Reported by: intrigeri Owned by: pospeselr
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: AffectsTails, tbb-7.0-issues, tbb-regression, tbb-e10s, TorBrowserTeam201712R, tbb-no-uplift
Cc: intrigeri, pospeselr, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

"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.

Child Tickets

Attachments (2)

0001-Conditionally-setlocale-based-on-javascript.use_us_e.patch (7.3 KB) - added by pospeselr 3 months ago.
Adds checks to use_us_english_locale setting before calling setlocale and friends
0001-Issue-23016-Print-to-File-does-not-create-the-expect.patch (9.4 KB) - added by pospeselr 3 months ago.
fixed macos build failure and updated commit message explaining the problem and solution

Download all attachments as: .zip

Change History (40)

comment:1 Changed 7 months ago by intrigeri

Cc: intrigeri added

comment:2 Changed 7 months ago by gk

Keywords: tbb-7.0 tbb-regression added

comment:3 Changed 7 months ago by gk

Keywords: tbb-7.0-issues added; tbb-7.0 removed

comment:4 Changed 5 months ago by intrigeri

This feels like basic functionality to me, but I understand that the TBB team has probably higher priority items on their plate. Fine :)

Any hint you folks can share, in case I want to look deeper myself?

comment:5 in reply to:  4 Changed 5 months ago by gk

Cc: pospeselr added
Keywords: tbb-e10s added
Status: newneeds_information

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?

comment:6 Changed 5 months ago by pospeselr

Yeah sure!

comment:7 Changed 5 months ago by pospeselr

Owner: changed from tbb-team to pospeselr
Status: needs_informationassigned

comment:8 Changed 5 months ago by mcs

Cc: mcs added

comment:9 Changed 5 months ago by mcs

Cc: brade added

comment:10 Changed 5 months ago by pospeselr

Works on my machine (Ubuntu 17.04, french locale) for both possible value for that property. Will spin up a VM with Debian unstable and see if I can repro there.

intrigeri: can you point me to what page you're trying to print?

comment:11 Changed 5 months ago by gk

For me any page is sufficient. Take for example about:tor. Here is what I did (with an en-US bundle):

1) I opened the hamburger menu in the upper right corner and selected the Print icon.
2) I clicked on the Print... button, selected Print to File, chose a name and clicked on Print.
3) I repeated 2) but no warning dialog appeared (notifying you that you are about to overwrite a file).
4) Upon looking in the directory where the file was supposed to be saved it turns out it was not.
5) Repeating 1) and 2) with multiprocess mode disabled solves it for me.

comment:12 Changed 5 months ago by 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?

comment:13 in reply to:  12 Changed 5 months ago by gk

Status: assignedneeds_information

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?

comment:14 Changed 5 months ago by 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.

Does this error happen for y'all on 64 or 32-bit? I've been doing all my testing on 64-bit so far.

comment:15 in reply to:  14 ; Changed 5 months ago by 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.

comment:16 in reply to:  15 ; Changed 5 months ago by 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?

Last edited 5 months ago by pospeselr (previous) (diff)

comment:17 in reply to:  16 Changed 5 months ago by gk

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?

comment:18 Changed 5 months ago by pospeselr

Yeah pdf gets saved to ~/Tor\ Browser successfully on both en-us and fr skus

comment:19 in reply to:  11 ; Changed 5 months ago by intrigeri

Replying to gk:

For me any page is sufficient. Take for example about:tor. Here is what I did (with an en-US bundle):

1) I opened the hamburger menu in the upper right corner and selected the Print icon.
2) I clicked on the Print... button, selected Print to File, chose a name and clicked on Print.
3) I repeated 2) but no warning dialog appeared (notifying you that you are about to overwrite a file).
4) Upon looking in the directory where the file was supposed to be saved it turns out it was not.
5) Repeating 1) and 2) with multiprocess mode disabled solves it for me.

I've tested again with AppArmor fully disabled (removed security=apparmor apparmor=1 from 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.

comment:20 in reply to:  19 ; Changed 5 months ago by intrigeri

Replying to intrigeri:

Replying to gk:
I've tested again with AppArmor fully disabled (removed security=apparmor apparmor=1 from 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).

comment:21 in reply to:  20 Changed 5 months ago by gk

Replying to intrigeri:

Replying to intrigeri:

Replying to gk:
I've tested again with AppArmor fully disabled (removed security=apparmor apparmor=1 from 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.

comment:22 Changed 5 months ago by intrigeri

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.desktop i.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 cups but 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?

comment:23 Changed 5 months ago by gk

Not sure yet. Does the problem go away if you flip javascript.use_us_english_locale to false?

comment:24 Changed 5 months ago by pospeselr

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.

comment:25 in reply to:  23 Changed 5 months ago by intrigeri

Replying to gk:

Does the problem go away if you flip javascript.use_us_english_locale to false?

Yes! (On Tails 3.2)

comment:26 Changed 4 months ago by pospeselr

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.

comment:27 Changed 4 months ago by pospeselr

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.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:28 Changed 4 months ago by pospeselr

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?

Changed 3 months ago by pospeselr

Adds checks to use_us_english_locale setting before calling setlocale and friends

comment:29 Changed 3 months ago by pospeselr

Keywords: TorBrowserTeam201711R added
Status: needs_informationneeds_review

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 #23970 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

Last edited 3 months ago by pospeselr (previous) (diff)

comment:30 Changed 3 months ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201711R removed
Status: needs_reviewneeds_revision

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.

Changed 3 months ago by pospeselr

fixed macos build failure and updated commit message explaining the problem and solution

comment:31 Changed 3 months ago by pospeselr

Keywords: TorBrowserTeam201711R added; TorBrowserTeam201711 removed
Status: needs_revisionneeds_review

Fixed macos build failure, running into some rbm issues for windows.

Currently setting up OSX and Windows VMs to verify didn't break anything.

comment:32 Changed 3 months ago by pospeselr

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.

comment:33 Changed 3 months ago by gk

Keywords: TorBrowserTeam201712R added; TorBrowserTeam201711R removed

Moving review tickets over to December

comment:34 Changed 2 months ago by mcs

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.

comment:35 Changed 2 months ago by gk

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 8ea9839478bfddd4f078f16c9268edf1755e9cb0). Leaving it open for now to address mcs's questions in comment:34.

comment:36 Changed 2 months ago by pospeselr

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 ).

comment:37 Changed 2 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks! Closing this bug. mcs: If you feel there are still questions open, please reopen this bug.

comment:38 Changed 4 weeks ago by arthuredelstein

Keywords: tbb-no-uplift added
Note: See TracTickets for help on using tickets.