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

[Tor Bug Tracker & Wiki]

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

 * keywords:  ff60-esr, TorBrowserTeam201805R => ff60-esr,
     TorBrowserTeam201805
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:9 sysrqb]:
 > I'll set this to needs-review for the tor-launcher patches I have:
 > Branch bug25750 on git.tp.o/user/sysrqb/tor-launcher.git

 Kathy and I reviewed and ran the revised Tor Launcher in a ESR 60-ish
 browser. It is working pretty well – good work! We have a few comments:

 1) I am surprised that XPCOM extensions still work as well as they do. We
 should set `extensions.legacy.enabled = true` and add `tor-
 launcher at torproject.org` to `extensions.legacy.exceptions` so the
 about:addons UI does not label Tor Launcher as LEGACY (and also add
 Torbutton's extension ID if we keep them both as regular add-ons).

 2) For 5e5fba0951b0837948bd9c074a3710afe137d0eb, please omit the first
 change.

 3) For 6105ea64e74cf65e09755d917234fe63b49b84ba, you could use a shorter
 commit message, e.g.,
  Mozilla dropped support for Ci.nsIProgrammingLanguage.JAVASCRIPT
  See https://bugzilla.mozilla.org/show_bug.cgi?id=1149830#c18

 4) For 068b9b5e8bb0408879b984c7c7ebd3726f25dd6c you could shorten the
 commit message and reference the entire bugzilla.mozilla.org URL. Maybe
 just use:
     Gecko now requries "0o"-prefixed octal literals
     See https://bugzilla.mozilla.org/show_bug.cgi?id=1263074

 5) For 374b64f3057ab4b703e3e79473cd4cfc8abc295e:
 * How can we guarantee that the call to `_loadPreferences()` occurs before
 any code which might rely on the preference values? Kathy and I don't have
 an answer, but maybe we should add an explicit initialization call inside
 `components/tl-process.js` (either in the `"profile-after-change"` case
 within the `observe()` implementation or at the end of `tl-process.js`.
 * Please use `let` instead of `var` in new code when possible (we are
 migrating in that direction).
 * Please use the Cc and Ci constants.
 * Please log a message when ignoring invalid pref names (near the top of
 the `pref()` function).
 * You can use `this.mPrefsSvc` inside `_getPrefDefaultBranch()`; if you do
 that, it might not be worthwhile to have a `_getPrefDefaultBranch()`
 function.

 6) For d1efcd33ca6389479337f70a603c73c8264888b8:
 * Mozilla now uses Services.intl.DateTimeFormat(). We should too. See:
 https://hg.mozilla.org/releases/mozilla-beta/rev/650bd331efd0
 * I don't think we should add a blank line after this one:
   let fracSecsStr = ...
 (that declaration is tied to the `for` loop that follows immediately
 after).

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