With sandboxing enabled on Vista, 32-bit Firefox uses another 64-bit process (wow_helper.exe) to patch functions in the loaded ntdll.dll in the child content process. However, we are not building wow_helper.exe and it is not present, so the content process creation method silently fails. We 'could' go in and properly update the build system to build wow_helper.exe with 64-bit mingw. However, Vista support is going away very soon for Tor Browser once we update to a newer Firefox ESR. Therefore, the more prudent fix is to simply disable sandboxing when running on Vista or lower in this WOW64 scenario, rather than to do the work to get wow_helper.exe building only to have to rip it all out in a few months when we rebase with latest Firefox ESR. This logic is ifdef'd out for 64-bit builds. Verified the Tor Browser works as expected in following scenarios: 32-bit Firefox on 32-bit Windows Vista -> Sandbox enabled 32-bit Firefox on 64-bit Windows Vista -> Sandbox disabled 32-bit Firefox on 64-bit Windows 7 -> Sandbox enabled
Ported over firefox patch 997c6b961cd0 (Bug 1329835)
Ported over firefox patch 5e7872cb3b5c (Bug 1364627)
Ported over firefox patch 5b9702d8fe4e (Bug 1309205 Part 3)
Ported over firefox patch 2797f193a147 (Bug 1309205 Part 2)
Ported over firefox patch 5c25a123203a (Bug 1309205 Part 1)
The Problem: During firefox and Web Content process startup, ::OverrideDefaultLocaleIfNeeded() is called which will conditionally ::setlocale() to "C.UTF-8" or "C" based off of the javascript.use_us_english_locale preference (to prevent fingerprinting based on how dates and what-not are formatted). Sometime after this call in the Web Content process the locale is set to the system's locale which effectively stomps over the work done by the ::OverrideDefaultLocaleIfNeeded() call. As a result, the firefox process and the Web Content process are configured to use different locales; firefox uses "C.UTF-8" while Web Content uses "" (system default). On Linux, the "Print to File" printer is a default GTK printer whose name is localized based off of the process's locale. The GTK print dialog is hosted in the firefox process and therefore the printer name will be 'Print to File.' This process sends this name over to the Web Content process, which iterates over the list of printers and finds one whose name matches. However, as the Web Content process's locale is set to system, its printer names will be localized and in the language of the system, so no printer with the name 'Print to File' will be found, and printing fails. This is why disabling javascript.use_us_english_locale fixes the issue. It also explains why disabling multi-process mode via the browser.tabs.remote.autostart.2 preference fixes the issue; one process means the printer-name is never used as a selector and also means no mismatched locale can happen. The Solution: The fix for this issue is to first check the javascript.use_us_english_locale preference each place in code where setlocale occurs, particularly in the nsLocaleService object which is the particular code path which overrides setlocale in the Web Content process.
This adds a test case to test that network information is correctly spoofed when 'privacy.resistFingerprinting' is true. Firefox ESR 52 does not have the navigation object inside workers. Thus, the worker test was removed. MozReview-Commit-ID: Lt6HZlFrcja --HG-- extra : rebase_source : 70d44115532549814af9fce3af9fe379e36bca80
This patch makes the network information API always returns the default type 'unknown' and blocking the ontypechange event while connection type changed when 'privacy. resistFingerprinting' is true. MozReview-Commit-ID: 4eOdHgAGtyY --HG-- extra : rebase_source : 78449fb4888b787062ff2139e36c219e0eac0b2c
The plugin-container process can thrash/crash due to increasing memory consumption after our workaround for bug 24052. The patch provided by a cypherpunk (bug thanks!) deals with that as far as the Developer Tools are concerned.