In Chromium extensions, the viewer's URL looks like this:
chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf
Furthermore, the PDF Viewer itself can also add something to the reference fragment:
chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf#page=2
Consequently, it is difficult to copy a clean URL (e.g. for sharing over mail)
without having to tidy-up the URL manually.
This commit solves this issue by adding a button to the omnibox,
which shows the clean PDF URL on click.
Before commit:
chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf
After commit:
chrome-extension://EXTENSIONID/http://example/file.pdf
Technical details:
- The extension's background page uses the webRequest API to intercept
requests for <extension host>/<real path to pdf>, and redirect it to
the viewer's URL.
- viewer.js uses history.replaceState to rewrite the URL, so that it's
easier for users to recognize and copy-paste URLs.
- The fake paths /http:, /https:, /file:, etc. have been added to the
web_accessible_resources section of the manifest file, in order to
avoid seeing chrome-extension://invalid/ instead of the actual URL
when using history back/forward to navigate from/to the PDF viewer.
- Since the relative path resolving doesn't work because relative URLs
are inaccurate, a <base> tag has been added. This method has already
been proven to work in the Firefox add-on.
Notes:
- This commit has been cherry-picked from crx-using-streams-api.
- Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with
a bug in Chrome <=30
- In Chrome, getting the contents of a FTP file is not possible, so
there's no support for FTP files, even though the extension router
recognizes the ftp: scheme.
The current stable Chromium version is 29. Since the critical
bug that prevented use of incognito:split has been fixed, and
incognito:split is actually used, it's safe to drop the code
that disables the extension in incognito mode.
( fixed bug = http:/crbug.com/224094 )
And use split incognito mode
Previous method:
- Rewrite content type to XHTML, followed by a content script
to cancel and replace the document with the viewer.
( https://github.com/mozilla/pdf.js/pull/3017 )
New method:
- Cancel loading of the document, followed by a redirect to the viewer
Disadvantage of new method:
- URLs are no longer "nice". This will be addressed by cherry-picking
a commit from the crx-using-streams-api branch.
Advantages of new method:
- Idle time is minimal. In some cases (with large documents),
it took too much time before the content script was activated.
During this period, the page looked blank, and the contents of
the PDF file were still retrieved and **discarded**.
With the new method, the idle time is minimal, because the request
is immediately cancelled.
- No FOUXEP (Flash of unhidden XML error page), because the XHTML
Content-Type hack is no longer used.
pdfHandler-local.js references the isPdfDownloadable function from
pdfHandler.js, but the function didn't expect that the responseHeaders
property was absent. Added a check to prevent a runtime error when a
local file is displayed in a frame, and show local PDF files again.
Local files are rendered on the chrome-extension:-protocol. The previous
method of getting the PDF URL was incorrect, this has been fixed as well.
Sometimes, the viewer did not render for PDF files in an iframe,
because document.readyState not reaching "complete".
Deferring window.stop() until the root element is placed in the
document fixes the problem (typically a few ten milliseconds).
A user reported that the PDF Viewer is not rendered on Dropbox,
(Chrome on Mac OS X). This is apparently caused by the fact that the
PDF file is loaded in an iframe in such a way that the tabs.onUpdated
event is not triggered.
This patch switches to the webNavigation event API, which improves the
reliability of the navigation detection.
Unfortunately Opera 15 does not support the webNavigation API, so the
old (tabs.onUpdated) method is used (feature-detection is used, so
whenever Opera decides to implement this API, it will profit from it).
The Chrome extension activates PDF.js by inserting the script tags
in a document whose URL and location origin is identical to the PDF
file.
Because of this, the path './images/' was resolved relatively to the
location of the PDF file instead of the extension.
To fix this, the IMAGE_DIR constant is moved outside the local scope,
to allow extensions/chrome/insertviewer.js to override the value.
Originally, the IMAGE_DIR variable was a global variable, but commit
f8f4b3f45d moved the global variable
to the local scope, causing the extension to malfunction.
Impact: low, the only consequence is that some rarely used images
were not visible.
Trivial test:
At the center of page 2, the annotation icon
(images/annotation-comment.svg) should be visible:
http://linorg.usp.br/CTAN/macros/latex/contrib/pdfcomment/doc/pdfcomment.pdf
Full list feature changes in this commit:
- Support for iframes
- Switched to content-type (MIME) detection instead of hard-coding a
case-sensitive check for the .PDF extension
- The PDF's original URL is visible in the omnibox
- Support for incognito mode
Note: PDF viewer is disabled for the file:// + incognito
combination, because it's currently impossible to get the combination
to work.
See https://github.com/mozilla/pdf.js/pull/3017#issuecomment-15693432
