[tbb-bugs] #14631 [Tor Browser]: Users that try to run from DMG files run into "Another copy of Firefox is running"
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Feb 14 00:30:07 UTC 2015
#14631: Users that try to run from DMG files run into "Another copy of Firefox is
Reporter: | Owner: tbb-team
arthuredelstein | Status: new
Type: defect | Milestone:
Priority: normal | Version:
Component: Tor | Keywords: tbb-usability, uxsprint2015, tbb-
Browser | usability-stoppoint-app, TorBrowserTeam201502
Resolution: | Parent ID:
Actual Points: |
Changes (by mikeperry):
* status: needs_information => new
Replying to [comment:8 mcs]:
> OK, there is good news and there is bad news. The good news is that
Kathy and I tracked down the spot in the code where we can detect failure
due to the profile being on a read-only file system (inside
nsProfileLock::LockWithFcntl()). And we can propagate a new nsresult out
and pass it into nsAppRunner.cpp's ProfileLockedDialog() function, and so
we can display a unique error message to cover this situation.
> The bad news is that, since the profile has not yet been loaded, we
cannot access Torbutton's string bundle... which is where we would
typically put a new localizable string for the new error message. Here
are a few options:
> 1. Use a hard-coded English string.
> 2. Start including new localized strings in Tor Browser somehow. This
might be difficult to manage with our existing Transifex-based process. I
think we should avoid going down this path.
> 3. Resolve this ticket as "won't fix" and hope that efforts we make for
#14687 will keep users out of trouble.
> 4. Your idea here.
This is unfortunate. However, all hope is not lost. With some disgusting
hacks, we should still be able to access torbutton.properties strings at
this point. Basically, we need to construct a URI like:
where some code gets the current working directory of the browser and does
some magic to determine the right locale directory and sets CWD and LOCALE
Once we have this jar URI for the current directory and current locale, we
should be able to pass that jar URI into https://developer.mozilla.org/en-
You can then extract the strings as per the normal string bundle APIs and
shove them into the error dialog.
(Note also that setting Torbutton LOCALE directory properly also seems to
be slightly tricky, as the Torbutton locale directories do not appear to
cleanly match the current Firefox '''general.useragent.locale''' pref
values. Torbutton omits country codes in some but not all cases, but there
must be some code that does this conversion already, as it works for
Firefox's build-in localization currently, but I am not sure where this
This hack should be neatly abstracted from the rest of the patch, as I
suspect that a generic "This profile directory cannot be written to" error
message fix is something that Mozilla would take, if they don't flee in
terror upon the sight of this localization hack.
Is this too insane? I think given that the alternative is to somehow
rebuild all of the Mozilla language pack XPIs just to pick up this new
resource, this might be cleaner. Or maybe not. We're starting to run into
quite a few situations where we're referencing Torbutton strings in the
browser, so perhaps deploying a proper localization solution for the
browser is something we should do..
Either way, I think given the frequency of this issue (as per frequent
helpdesk reports about #4782), we should invest the effort in some kind of
localized and user-intelligible error message here, though.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14631#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs