[Firefox] Allow PDF attachments to, once again, be opened directly in the browser (bug 1632644)
Apparently the old link format used in MOZCENTRAL-builds, with the blob URL separated from the filename with a `?` character violates the specification; see https://bugzilla.mozilla.org/show_bug.cgi?id=1632644#c5 Obviously just removing the `?`-part of the URL would have worked, but that would also have meant that we'd no longer be able to provide the correct filename when the user attempts to download the opened PDF attachment. To fix this we'll instead append the filename in the hash-part of the URL, which however required using a *custom* hash-parameter to avoid triggering the fallback "named destination" code-paths in the viewer. Note that only changing the `web/pdf_attachment_viewer.js` file wasn't sufficient to fix the bug, and we also need to tweak the `webViewerInitialized` function in `web/app.js` since MOZCENTRAL-builds used to ignore *everything* in the URL hash. This particular code is very old, but changing it *should* be completely safe given that the `PDFViewerApplication.setTitleUsingUrl` method since some time now stores both the original URL (in `this.url`) as well as one without the hash (in `this.baseUrl`). The latter one is already used everywhere where it matters, so this change seem fine to me. This patch thus restores the original behaviour for PDF attachments in the MOZCENTRAL-build, by once again allowing them to be opened *directly* in the browser without downloading. (The fallback added in PR 11845 is obviously kept, since it seems generally useful to have.)
This commit is contained in:
parent
6ffcedc24b
commit
108258a8f8
@ -1858,7 +1858,7 @@ function webViewerInitialized() {
|
||||
file = "file" in params ? params.file : AppOptions.get("defaultUrl");
|
||||
validateFileURL(file);
|
||||
} else if (PDFJSDev.test("MOZCENTRAL")) {
|
||||
file = window.location.href.split("#")[0];
|
||||
file = window.location.href;
|
||||
} else if (PDFJSDev.test("CHROME")) {
|
||||
file = AppOptions.get("defaultUrl");
|
||||
}
|
||||
|
@ -95,7 +95,7 @@ class PDFAttachmentViewer {
|
||||
viewerUrl = "?file=" + encodeURIComponent(blobUrl + "#" + filename);
|
||||
} else if (PDFJSDev.test("MOZCENTRAL")) {
|
||||
// Let Firefox's content handler catch the URL and display the PDF.
|
||||
viewerUrl = blobUrl + "?" + encodeURIComponent(filename);
|
||||
viewerUrl = blobUrl + "#filename=" + encodeURIComponent(filename);
|
||||
} else if (PDFJSDev.test("CHROME")) {
|
||||
// In the Chrome extension, the URL is rewritten using the history API
|
||||
// in viewer.js, so an absolute URL must be generated.
|
||||
|
@ -610,7 +610,7 @@ function getPDFFileNameFromURL(url, defaultFilename = "document.pdf") {
|
||||
return defaultFilename;
|
||||
}
|
||||
const reURI = /^(?:(?:[^:]+:)?\/\/[^\/]+)?([^?#]*)(\?[^#]*)?(#.*)?$/;
|
||||
// SCHEME HOST 1.PATH 2.QUERY 3.REF
|
||||
// SCHEME HOST 1.PATH 2.QUERY 3.REF
|
||||
// Pattern to get last matching NAME.pdf
|
||||
const reFilename = /[^\/?#=]+\.pdf\b(?!.*\.pdf\b)/i;
|
||||
const splitURI = reURI.exec(url);
|
||||
|
Loading…
x
Reference in New Issue
Block a user