According to https://wiki.mozilla.org/RapidRelease/Calendar#Past_branch_dates: The *last* ESR version of Firefox 38 was released in April this year, and since June the only available ESR version has been based on Firefox 45.
Now that Seamonkey has *finally* released a new version, i.e. 2.46 which should correspond to Firefox 49, there doesn't seem to be any reason to keep the fallback code around in the addon anymore.
*Please note that most of the necessary code adjustments were made in PR 7890.*
ESLint has a number of advantageous properties, compared to JSHint. Among those are:
- The ability to find subtle bugs, thanks to more rules (e.g. PR 7881).
- Much more customizable in general, and many rules allow fine-tuned behaviour rather than the just the on/off rules in JSHint.
- Many more rules that can help developers avoid bugs, and a lot of rules that can be used to enforce a consistent coding style. The latter should be particularily useful for new contributors (and reduce the amount of stylistic review comments necessary).
- The ability to easily specify exactly what rules to use/not to use, as opposed to JSHint which has a default set. *Note:* in future JSHint version some of the rules we depend on will be removed, according to warnings in http://jshint.com/docs/options/, so we wouldn't be able to update without losing lint coverage.
- More easily disable one, or more, rules temporarily. In JSHint this requires using a numeric code, which isn't very user friendly, whereas in ESLint the rule name is simply used instead.
By default there's no rules enabled in ESLint, but there are some default rule sets available. However, to prevent linting failures if we update ESLint in the future, it seemed easier to just explicitly specify what rules we want.
Obviously this makes the ESLint config file somewhat bigger than the old JSHint config file, but given how rarely that one has been updated over the years I don't think that matters too much.
I've tried, to the best of my ability, to ensure that we enable the same rules for ESLint that we had for JSHint. Furthermore, I've also enabled a number of rules that seemed to make sense, both to catch possible errors *and* various style guide violations.
Despite the ESLint README claiming that it's slower that JSHint, https://github.com/eslint/eslint#how-does-eslint-performance-compare-to-jshint, locally this patch actually reduces the runtime for `gulp` lint (by approximately 20-25%).
A couple of stylistic rules that would have been nice to enable, but where our code currently differs to much to make it feasible:
- `comma-dangle`, controls trailing commas in Objects and Arrays (among others).
- `object-curly-spacing`, controls spacing inside of Objects.
- `spaced-comment`, used to enforce spaces after `//` and `/*. (This is made difficult by the fact that there's still some usage of the old preprocessor left.)
Rules that I indend to look into possibly enabling in follow-ups, if it seems to make sense: `no-else-return`, `no-lonely-if`, `brace-style` with the `allowSingleLine` parameter removed.
Useful links:
- http://eslint.org/docs/user-guide/configuring
- http://eslint.org/docs/rules/
From the discussion in issue 7386, it wasn't really clear if we can restrict addon support to Firefox `45` (i.e. the version that corresponds to the *current* ESR version).
However, we have a bunch of code for *very* old Firefox versions. Hence this patch changes the minimum supported version to Firefox `38` (which was released on `2015-05-12`, and correspond to the *previous* ESR version), and removes code that only applies to old Firefox versions.
Regardless what we end up deciding regarding addon support for previous Firefox versions, given the amount of code that even the Firefox `>= 38` condition lets us remove, I certainly think that there is value in doing this.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1170063.
The bug only mentions the <kbd>Meta</kbd> key, but given that a similar situation can occur for <kbd>Ctrl</kbd>, it seemed reasonable to also handle that case in the same patch.
The only possible caveat with the patch is that because of the use of `shadow`, things won't work perfectly if either of the prefs are changed *while* the viewer is active. In this case a reload is required in order for it to work correctly, but given that the issue this patch fixes should be quite rare anyway, that seems OK.
For some reason, https://bugzilla.mozilla.org/show_bug.cgi?id=1167053 changed methods of `NetUtil` yet *again*. This patch thus attempts to handle those changes, while keeping the addon backwards compatible.
I've tested this using all current Firefox versions (Nightly, Aurora/DevEdition, Beta, Release, ESR), and things still appears to work correctly.
This patch removes the only remaining CPOW usage from the code-base, and should thus fix https://bugzilla.mozilla.org/show_bug.cgi?id=1071082.
*Note:* This will not fix the "Open With Different Viewer" button in e10s, since clicking it still fails with `frontWindow is null` in the console, but I do believe that that issue is somewhat orthogonal to the current patch.
This checks for both prefs on the understanding that we need to work on older versions of Firefox. If that isn't the case, the first part of the if isn't necessary. This should only land if bug 639134 is resolved - I'd make the patch part of that bug, but AIUI pdfjs's canonical repo is on github, so...
As of Firefox 35, isContentWindowPrivate should be used for DOM windows instead of isWindowPrivate.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1069059 and
http://hg.mozilla.org/mozilla-central/diff/324798b60ba3/toolkit/modules/PrivateBrowsingUtils.jsm
Without this fix, you will get the following error message when Firefox+PDF.js is started:
>
WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isWindowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14
ChromeActions.prototype.isInPrivateBrowsing@resource://pdf.js/PdfStreamConverter.jsm:237:12
xhr_onreadystatechange@resource://pdf.js/PdfStreamConverter.jsm:545:30
NetworkManager_requestRange@resource://pdf.js/network.js:95:7
NetworkManager_requestRange@resource://pdf.js/network.js:81:14
RangedChromeActions_requestDataRange@resource://pdf.js/PdfStreamConverter.jsm:596:1
RequestListener.prototype.receive@resource://pdf.js/PdfStreamConverter.jsm:705:5
PdfStreamConverter.prototype.onStartRequest/proxy.onStopRequest/<@resource://pdf.js/PdfStreamConverter.jsm:909:11
FirefoxComClosure/<.request@resource://pdf.js/web/viewer.js:529:14
PdfDataRangeTransport_requestDataRange@resource://pdf.js/web/viewer.js:2977:9
transportDataRange@resource://pdf.js/build/pdf.js:2122:13
messageHandlerComObjOnMessage@resource://pdf.js/build/pdf.js:1219:9
