akira/pdfjs-dist - pdfjs-dist - Gitea: Git with a cup of tea

Tree: 47789b51c3

Author	SHA1	Message	Date
Rob Wu	19549bb7d6	[CRX] Integrate cursorToolOnLoad pref + migration logic Add UI for the cursorToolOnLoad pref in the UI of the Chrome extension. Add logic to migrate the enableHandToolOnLoad pref to cursorToolOnLoad. For past values in the mutable extension storage area: 1. If enableHandToolOnLoad=true, save cursorToolOnLoad=1. 2. Remove enableHandToolOnLoad. For the managed extension storage, which is immutable since it is based on administrative policies, use the following logic: 1. If enableHandToolOnLoad=true and cursorToolOnLoad=0 (default). set cursorToolOnLoad=0 and assume enableHandToolOnLoad=false. 2. As usual, managed preferences can (and will) be overridden by the user. The first migration logic is in extensions/chromium/options/migration.js and can be removed after a few months / less than many years. The second migration logic is in web/chromecom.js, and should be kept around for a long while (many years). The need for this migration logic arises from the change by: https://github.com/mozilla/pdf.js/pull/7635	8 years ago
Nimesh Solanki	e004b3cfab	update inconsistent names	8 years ago
Jonas Jenwald	4f48c8198c	Fix inconsistent spacing and trailing commas in objects in `extensions/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in in one big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/extensions/firefox/content/PdfStreamConverter.jsm b/extensions/firefox/content/PdfStreamConverter.jsm index ea91a71a..0d59dad1 100644 --- a/extensions/firefox/content/PdfStreamConverter.jsm +++ b/extensions/firefox/content/PdfStreamConverter.jsm @@ -773,7 +773,8 @@ class RequestListener { response = function sendResponse(aResponse) { try { var listener = doc.createEvent("CustomEvent"); - let detail = Cu.cloneInto({ response: aResponse, }, doc.defaultView); + let detail = Cu.cloneInto({ response: aResponse, }, + doc.defaultView); listener.initCustomEvent("pdf.js.response", true, false, detail); return message.dispatchEvent(listener); } catch (e) { ```	8 years ago
Mark Banner	2e9ae50a3a	Use eslint-plugin-mozilla and the webextensions environment to avoid defining globals in each file.	8 years ago
Jonas Jenwald	c850968fa7	Remove `globals` that are now unnecessary thanks to the use of various ESLint environments (e.g. Node, ShellJS, Jasmine)	8 years ago
Jonas Jenwald	2f3805efbc	Switch to using ESLint, instead of JSHint, for linting 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/	8 years ago
Rob Wu	0be8e72d6f	Support syncing of settings in Chrome extension Use chrome.storage.sync to store preferences instead of chrome.storage.local, to allow settings to be synchronized if the user chooses to sign in in Chrome and enables synchronization of extension preferences.	9 years ago
Tim van der Meij	fdfaa43f5e	Resolve a regression in the Chromium extension's preferences handling Commit `df10513e10` unfortunately broke the options dialog of the Chromium extension because the logic required to work with the preference was not added. This patch adds the required logic to show the preference in the options dialog and to persist it to the preferences storage. Verified using Chromium 50 on Arch Linux.	9 years ago
Manas	a2ba1b8189	Uses editorconfig to maintain consistent coding styles Removes the following as they unnecessary /* -- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -- / / vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */	10 years ago
Rob Wu	1b043bfd5a	Chrome extension: Add options page	10 years ago