From f2753d62204b1a41f2ece87ab854c0b919013686 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Sun, 2 Jul 2023 15:31:35 +0200 Subject: [PATCH] [CRX] Avoid encoding the fragment in file key Semantically, it is more correct to encode the fragment in the URL instead of the URL-encoded `file` query parameter. This shouldn't matter in practice, because `rewriteUrlClosure` in `chromecom.js` decodes the `file` parameter and restores the fragment. However, as #16625 shows, there was a case where this did not work as expected. --- extensions/chromium/pdfHandler.js | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/extensions/chromium/pdfHandler.js b/extensions/chromium/pdfHandler.js index 3b014db5c..36d070e48 100644 --- a/extensions/chromium/pdfHandler.js +++ b/extensions/chromium/pdfHandler.js @@ -20,7 +20,15 @@ limitations under the License. var VIEWER_URL = chrome.extension.getURL("content/web/viewer.html"); function getViewerURL(pdf_url) { - return VIEWER_URL + "?file=" + encodeURIComponent(pdf_url); + // |pdf_url| may contain a fragment such as "#page=2". That should be passed + // as a fragment to the viewer, not encoded in pdf_url. + var hash = ""; + var i = pdf_url.indexOf("#"); + if (i > 0) { + hash = pdf_url.slice(i); + pdf_url = pdf_url.slice(0, i); + } + return VIEWER_URL + "?file=" + encodeURIComponent(pdf_url) + hash; } /**