[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #14631 [Tor Browser]: Users that try to run from DMG files run into "Another copy of Firefox is running"

#14631: Users that try to run from DMG files run into "Another copy of Firefox is
running"
-------------------------+-------------------------------------------------
     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:           |
       Points:           |
-------------------------+-------------------------------------------------
Changes (by mikeperry):

 * status:  needs_information => new


Comment:

 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:
 '''jar:file:///CWD/Browser/TorBrowser/Data/Browser/profile.default/extensions/torbutton@xxxxxxxxxxxxxxxxxx!/chrome/locale/LOCALE/torbutton.properties''',
 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
 appropriately.

 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-
 US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIStringBundleService#createBundle%28%29.
 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
 code is).

 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs