Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
*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/
This patch moves the user agent checks to the top of the file to reduce
duplication and to provide a clear overview of which user agent we are
detecting.
Moreover, we extract inline user agent checks as well and use existing
checks in more places. Finally, we fix the indenting in one place for
consistency.
According to e.g. issue 7754, it appears that the current `isSafari` check is failing in newer version of the browser. Despite the fact that checking the userAgent is an anti-pattern, which should be avoided, it's currently the simplest solution.
Instead of trying to hack around various browser defects, let's just disable PresentationMode in the affected browsers. This patch:
- Disables PresentationMode in IE11+ when the viewer is embedded; fixes 4711.
See "Case-insensitive language comparisons per RFC 4646"
https://github.com/fabi1cazenave/webL10n/pull/51
Removed the "patch" in compatibility.js and fixed the bug in webL10n,
because the logic belongs to webL10n instead of PDF.js.
The immediate motivation for this patch is that Chrome 40 converts
navigator.language to lower case: https://crbug.com/454331
Previously, reconstruction of arguments was incorrect if arguments contained
arrays. Arrays were added to arguments as their elements and not as a whole
array. It is enough to simply pass whole array to concat and it will be (only
one level deep) added to arguments.
In addition, we call slice on arguments for maximum compatibility (it is used
in Underscore.js library, with which I was comparing implementations while
debugging).
Declares the URL variable globally. If the feature is not
supported, the variable will still be declared, but have the
"undefined" value.
Supported by:
- Firefox 4
Firefox 21 in Web worker
- Chrome 8 (prefixed as webkitURL), 23+ unprefixed
Chrome 10 (prefixed as webkitURL) in Web Worker, 23+ unprefixed
- Opera 15
Opera 15 in Web Worker
- Internet Explorer 10
Internet Explorer 11 in Web Worker
- Safari 6 (prefixed as webkitURL)
Safari 6 (prefixed as webkitURL) in Web Worker
