[tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon May 14 21:14:50 UTC 2018


#25750: update Tor Launcher for ESR 60
--------------------------------------------+------------------------------
 Reporter:  mcs                             |          Owner:  brade
     Type:  defect                          |         Status:  needs_review
 Priority:  Very High                       |      Milestone:
Component:  Applications/Tor Launcher       |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by mcs):

 Replying to [comment:23 sysrqb]:
 > Although I agree with what I said, it's a terrible UX for users, so we
 should tell the user (somehow) that Tor Browser is in an undefined state.
 The only other option I see is we get rid of prefs.js entirely and somehow
 make sure all get...Prefs() calls use the correct default prefs.

 I think this situation is rare enough that we should not spend a lot of
 time trying to make it better from a UX perspective. Users should not edit
 the prefs.js file that is embedded in Tor Launcher (which is the most
 likely reason that loading the default prefs might fail).

 > Similar to what was mentioned above. I worry about this situation, but
 as long as we're careful about keeping prefs.js and the getIntPrefs()
 calls synchronized, this shouldn't be a problem.

 Kathy and I agree.

 > Right, so we have a few options and available formats, from what I see.
 The built-in formats do not play nicely with appending the milliseconds at
 the end, because some locales use 12-hour clocks and have AM/PM suffix,
 plus some add the timezone. We'd need additional logic for detecting this.
 The four built-in formats for en-US are (with milliseconds appended):
 >
 > {{{
 > dateStyle: "long", timeStyle: "long"
 > May 11, 2018, 8:45:58 PM UTC.436
 >
 > dateStyle: "short", timeStyle: "long"
 > 5/11/18, 8:45:58 PM UTC.436
 >
 > dateStyle: "long", timeStyle: "short"
 > May 11, 2018, 8:45 PM.436
 >
 > dateStyle: "short", timeStyle: "short"
 > 5/11/18, 8:45 PM.436
 > }}}
 >
 > I'd like feedback about the best direction we should go with these.

 Kathy and I spent a little time looking for an alternative. It seems we
 have more control if we use JavaScript's built-in Intl.DateTimeFormat
 object, i.e.,
 {{{
 let options = { year: '2-digit', month: 'numeric', day: 'numeric',
                 hour: 'numeric', minute: 'numeric', second: 'numeric',
                 hour12: false };
 let timeStr = new Intl.DateTimeFormat('en-US', options)
                       .format(logObj.date, options);
 }}}

 We have a few review comments for your bug25750_2 branch but we will post
 those in a separate comment.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25750#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list