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.

Sign up for GitHub

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

Jump to bottom

Correct recognition of fragments at document load #16630

Merged
merged 2 commits into from
Jul 8, 2023
Merged

Correct recognition of fragments at document load #16630

merged 2 commits into from
Jul 8, 2023

Commits on Jul 2, 2023

  1. [CRX] Re-initialize initialBookmark after URL rewrite 

    `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`.
    @Rob--W
    Rob--W committed Jul 2, 2023
    Configuration menu
    Copy the full SHA
    1d07ef4 View commit details
    Browse the repository at this point in the history

  2. [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 mozilla#16625 shows,
there was a case where this did not work as expected.
    @Rob--W
    Rob--W committed Jul 2, 2023
    Configuration menu
    Copy the full SHA
    f2753d6 View commit details
    Browse the repository at this point in the history