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.
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.
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."
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.
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.
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.
