Opened 8 years ago

Closed 8 years ago

#3686 closed defect (fixed)

Loading of system homepage is broken when Tor is enabled on start

Reported by: lunar Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Torbutton Version: Torbutton: 1.4.0
Severity: Keywords:
Cc: lunar@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If a system-wide homepage is set in Firefox, when Torbutton is installed and Tor enabled on start, the homepage is unfortunately not shown.

The patch available at http://patch-tracker.debian.org/patch/series/view/torbutton/1.4.0-2/fix-loading-of-system-homepage.patch fix the issue by looking up at the .properties file if needed.

Child Tickets

Attachments (1)

0001-Bug-3686-Fix-loading-of-localized-system-homepage.patch (1.9 KB) - added by lunar 8 years ago.
Properly use nsIPrefLocalizedString this time

Download all attachments as: .zip

Change History (6)

comment:1 Changed 8 years ago by lunar

Status: newneeds_review

comment:2 Changed 8 years ago by mikeperry

The patch has no commit message. I assume it is getting a localized version of the homepage based on locale.

What else is in this homepage? Something tells me it is debian-specific and not something we want loaded over tor anyways?

comment:3 Changed 8 years ago by lunar

This issue looks similar to me that the one that was fixed in 651be65f.

The default homepage setting in Debian is indeed i18nized by using nsIPrefLocalizedString, according to https://developer.mozilla.org/en/Code_snippets/Preferences#nsIPrefLocalizedString

The way Torbutton currently reload the homepage set in the preferences result in a blank homepage with only a monospaced 'chrome://branding/locale/browserconfig.properties' displayed. This happens if Firefox is started with TorButton in disabled state. Or in Tails as it uses a similar mechanism to open https://check.torproject.org/ localized to language selected at boot time.

Changed 8 years ago by lunar

Properly use nsIPrefLocalizedString this time

comment:4 Changed 8 years ago by lunar

The attached patch replaces the call to getCharPref() by the (not really) more convoluted getComplexValue(…, Components.interfaces.nsIPrefLocalizedString).data. Looks like the later falls back nicely when the preference in not part of a stringbundle.

comment:5 Changed 8 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Merged. Thanks for cleaning this up!

Note: See TracTickets for help on using tickets.