Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct recognition of fragments at document load #16630

Merged
merged 2 commits into from
Jul 8, 2023

Conversation

Rob--W
Copy link
Member

@Rob--W Rob--W commented Jul 2, 2023

Fixes #16625.

`PDFViewerApplication` reads from `location.hash` to initialize
`initialBookmark`. But when extensions/chromium/pdfHandler.js prepares
the redirect URL, the reference fragment is encoded instead of bare.
`rewriteUrlClosure` in `chromecom.js` is responsible for decoding the
URL, but that currently runs too late.

To fix this, update `initialBookmark` after rewriting the URL.

This was not a problem in the past because `rewriteUrlClosure` in
`chromecom.js` executed before the initialization of `initialBookmark`.
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 mozilla#16625 shows,
there was a case where this did not work as expected.
@timvandermeij timvandermeij merged commit 42edc4d into mozilla:master Jul 8, 2023
3 checks passed
@timvandermeij
Copy link
Contributor

Thank you for fixing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Not jumping to page number in URL which is suffixed with #page=<pagenum>
2 participants