#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 sysrqb): Replying to [comment:24 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. > Great, thanks! I added a commit that synchronizes a few get..Pref() calls default values. I don't think we need all of them in sync, but it seems safer if retrieving a pref during initialization uses the same default value as defined in prefs.js. > > 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): > > > > 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); > }}} > Thanks, that looks good. The only difference I see is this format inserts a comma between the date and time. {{{ 5/15/18, 23:20:43.525 [NOTICE] Bootstrapped 100%: Done }}} Replying to [comment:25 mcs]: > For 0219dcd1aaef1a5460bec39cdd95742222ff9c08, a couple of "leftover" functions are defined in `modules/tl-util.jsm` but they are not used; please remove them: > * `_defaultPrefsLoaded()` > * `loadDefaultPreferencesAndThrow()` Done. I pushed `bug25750_3` for review. Thanks. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25750#comment:26> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs