Given that this patch causes a lot of churn in the addon code, I wouldn't really mind if we ultimately decide against doing this and just add a rule exception in mozilla-central instead.[1]
---
[1] Note that I used the ESLint `--fix` option, hence writing this commit message actually took longer time than the creation of the patch :-)
PR 7322 added the `PdfJsNetwork.jsm` file, instead of the general `src/core/network.js` file for the Firefox addon. However, `make.js` wasn't updated to actually stop including the now obsolete network file.
*Please note: ignoring whitespace changes is most likely necessary for the diff to be readable.*
This patch addresses all the current, in `mozilla-central`, linting failures in the addon. It should thus be possible to change the `.eslintignore` entry for PDF.js in `mozilla-central` from `browser/extensions/pdfjs/**` to `browser/extensions/pdfjs/build/**` and `browser/extensions/pdfjs/web/**` instead.
Note that we cannot, for backwards compatibility reason of the general PDF.js library, at this time make similar changes for files residing in the `build` and `web` directories in `mozilla-central`.
The main changes in this patch are that we now use [classes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) instead of our previous "class-like" functions, and also use the more compact [object shorthand notation](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Object_initializer#New_notations_in_ECMAScript_2015).
A couple of functions were also converted to [arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions), to reduced usages of `bind(this)` and `var self = this`.
One caveat with ES6 classes is that it's not (yet) possible to define private constants/helper functions within them, which is why the `NetworkManagerClosure` was kept to not change the visibility of those constant/functions.
Besides testing in Firefox Nightly 53, this patch has also been tested in Firefox ESR 45 and SeaMonkey 2.46.
However, I'd gladly welcome help with testing the patch more, to ensure that nothing has gone wrong during the refactoring.
Fixes the first bullet point of issue 7957.
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.
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/
This patch implements the page label functionality in a similar way as Adobe Reader.
For documents with page labels, if a non-existent page label is entered we'll try to fallback to the page number instead.
The patch also includes a preference (`disablePageLabels`), to make it easy to opt-out of using page labels if the user/implementor so wishes.
The way that `get/set currentPageLabel` is implemented in `PDFViewer`, is as wrappers for the corresponding `get/set currentPageNumber` functions, since that seemed like the cleanest solution.
The page labels are purposely *only* added to the page controls in the viewer UI, and not stored in e.g. the `ViewHistory`. Since doing so would mean adding unnecessary code complexity, without any real added value, and would also mean delaying the inital loading of PDF documents.
Note that this patch will ignore page labels if they are identical to standard page numbering, since in this case displaying the page labels adds no value (but only UI noise). The reason for handling this case specially, is that in practice a surprising number of PDF files include "pointless" page labels.
A user encountered a response that looks like:
URL: some gibberish
Headers:
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="something.pdf"
In the Chrome extension, the "attachment" content disposition is almost
always ignored (i.e. the PDF Viewer will try to view it anyway). So we
need to fall back to the Content-Disposition header if the URL check is
inconclusive.
Please note that this is a hack, but I think that it should be OK for now to atleast get the preference landed. Refer to the code comment for further information.
Re: issue 7584 and PR 7586.
This patch is the first step towards implementing support for
interactive forms (AcroForms). It makes it possible to render text
widget annotations exactly like Adobe Reader/Acrobat.
Everything we implement for AcroForms is disabled by default using a
preference, mainly because it is not ready to use yet, but has to
implemented in many steps to avoid complexity. The preference allows us
to work with the code while not exposing the behavior by default. Mainly
storing entered values and printing them is still absent, which would be
minimal requirements for enabling this by default.
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.
Test:
1. Build the Chrome extension and load it.
2. Visit https://robwu.nl/pdfjs/object-embed.html
3. Verify that all displayed blocks have the same width and
height as the reference ("Expected dimension").
Privacy policy: https://github.com/Rob--W/pdfjs-telemetry#privacy-policy
Unit tests (offline):
```
node test/chromium/test-telemetry.js
```
Server tests (requires that Nginx is installed):
```
git clone https://github.com/Rob--W/pdfjs-telemetry.git
cd pdfjs-telemetry/
python testserver.py TestHttp TestHttps
```
Integration test (extension + server):
- Build the extension
- Edit build/chromium/telemetry.js and remove the check for
chrome.runtime.id.
- Start Chrome (preferably a new profile):
chromium --user-data-dir=/tmp/pdftest --no-first-run
- Open chrome://net-internals#events
- Visit chrome://extensions and enable Developer mode.
- Load unpacked extension, select build/chromium.
- Go to the chrome://net-internals tab and filter on pdfjs.robwu.nl.
- Click on URL_REQUEST and verify that the server replied with 204.
- Reload the extension.
- Verify that chrome://net-internals did not contain a new log request.
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.
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.
This was only ever useful for the Opera extension because the API
requires a whitelisted extension ID. Opera ditched PDF.js from their
extension gallery, so we don't need to keep this in the tree.
Multiple shadow roots are not supported any more in Chrome 51+
(https://crbug.com/603448#c6), so this patch changes the way that PDFs
are rendered in `<embed>` / `<object>` tags.
I used shadow roots because their content is not visible from the web
page, so the odds of conflicts were minimal. Now I have to render the
PDF frame directly in the page, which can be observed from the page
(unfortunately).
Now the following happens when an embedded PDF tag is detected:
- `<embed>` tags: The type and src attributes are updated.
- `<object>` tags: The type attribute is changed and the fallback
content is set and displayed.
This is required to be able to use it in the annotation display code,
where we now apply it to sanitize the filename of the FileAttachment
annotation. The PDF file from https://bugzilla.mozilla.org/show_bug.cgi?id=1230933 has shown that some PDF generators include the path of the file rather than the filename, which causes filenames with weird initial characters. PDF viewers handle this differently (for example Foxit Reader just replaces forward slashes with spaces), but we think it's better to only show the filename as intended.
Additionally we add unit tests for the `getFilenameFromUrl` helper
function.
The Chrome extension enforces that local files cannot be embedded in
non-local web pages. The previous check was too strict (because the
origin of a file:-URL is "null"), and prevented local PDF from being
viewed in local files).
This patch fixes that problem, by querying the actual tab URL via the
background page.
Steps to verify:
1. Create a HTML file: `<iframe src=test.pdf width=100% height=100%>`
2. Build and load the extension.
3. Allow file access to the extension at `chrome://extensions`
4. Open the HTML file from a file:// URL.
5. VERIFY: The extension should attempt to load the PDF file.
6. Now open the following (replace ID with the extension ID, which you
can find at `chrome://extensions`):
`data:text/html,<iframe src="chrome-extension://ID/file:///test.pdf">`
7. VERIFY: The next error should be displayed:
"Refused to load a local file in a non-local page for security reasons."
One of the patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1202902, specifically [`Mass replace toplevel 'let' with 'var' in preparation for global lexical scope. (rs=jorendorff)`](https://hg.mozilla.org/mozilla-central/rev/380817d573cd), touches PDF.js code. Unfortunately it was landed upstream without, as far as I can tell, notifying us about it.
This patch uplifts the relevant changes to avoid future merge conflicts, and for consistency also tweaks `PdfJs-stub.jsm`.
As explained in
https://github.com/mozilla/pdf.js/issues/6174#issuecomment-118502802.
To verify that this patch works:
1. Build the Chrome extension (node make chromium)
2. Load the Chrome extension (at chrome://extensions)
3. Visit https://robwu.nl/pdfjs/issue6174/.
4. Verify that PDF.js is not used to load the PDF. Either Chrome's
default PDF Viewer is used, or the PDF is offered as a file download.
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
Remove pageAction logic from extension router, and put it in a
separate file. The pageAction URL parsing logic has been simplified,
and all pageAction-related files have been moved to a separate directory.
document.documentElement.style is null in some XML documents.
The previous snippet caused the following error:
Uncaught TypeError: Cannot use 'in' operator to search for 'animation' in null
To fix this bug, `'animation' in document.documentElement.style` has been
replaced with `CSS.supports('animation', '9s')`. This method was introduced
in Chromium 28, but it is not necessary to detect whether this method is
supported because the required createShadowRoot method for embeds is not
available in Chromium 32 and earlier.
If a user downgrades from Chromium 35+ to 34, then the PDF Viewer
extension will not work any more because the extension assumes
that certain features were available based on the cached feature
detection results.
To resolve this problem, all feature detection scripts run again
if the browser was downgraded.
"text/javascript" is not a correct MIME type (the correct one is
"application/javascript") but it's not even needed; all browsers default
to the correct type and treat it as executable JS when type is ommited.
Since not all browsers recognize the "application/javascript" MIME type
the only way to both stay compliant and to support all popular browsers
is to omit the type. It's also shorter this way.
http://crbug.com/280464 has been resolved, so we can now use redirectUrl at
onHeadersReceived.
For backwards-compatibility, the code for the original method has not been
removed, and a feature detection script was added that detects whether the
desired feature is available.
