Ensure that the contentDispositionFilename is always respected, when setting the document title (PR 13014 follow-up)
#14964
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snuffleupagus
force-pushed
the
onOpenWithData-contentDispositionFilename
branch
from
d445a9e
to
872ca3b
Compare
|
This probably fixes #6396 (comment), but given that lack of a runnable test-case it's impossible to know for sure. /botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/6f14bd51c3c7445/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/6f14bd51c3c7445/output.txt Total script time: 2.51 mins Published |
Snuffleupagus
force-pushed
the
onOpenWithData-contentDispositionFilename
branch
from
872ca3b
to
a5eb433
Compare
…n setting the document title (PR 13014 follow-up) Currently, when range-requests and/or streaming are not supported or for documents opened from `data`-URLs, we'll manually set the `contentDispositionFilename` (assuming it exists and is valid) from the `onOpenWithData`-callback in `PDFViewerApplication.initPassiveLoading`. However, because of a small oversight in `PDFViewerApplication._initializeMetadata`, this *cached* `contentDispositionFilename` would be ignored and we'd only attempt to use the one returned by `PDFDocumentProxy.getMetadata` in the API (which in the cases outlined above will always be empty). Also, to ensure that the document properties dialog always displays the *correct* fileName we'll now lookup it using the same exact method as in the viewer itself (via a new callback-function).
Snuffleupagus
force-pushed
the
onOpenWithData-contentDispositionFilename
branch
from
a5eb433
to
0599ce7
Compare
timvandermeij
approved these changes
May 29, 2022
|
Looks good! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when range-requests and/or streaming are not supported or for documents opened from
data-URLs, we'll manually set thecontentDispositionFilename(assuming it exists and is valid) from theonOpenWithData-callback inPDFViewerApplication.initPassiveLoading.However, because of a small oversight in
PDFViewerApplication._initializeMetadata, this cachedcontentDispositionFilenamewould be ignored and we'd only attempt to use the one returned byPDFDocumentProxy.getMetadatain the API (which in the cases outlined above will always be empty).Also, to ensure that the document properties dialog always displays the correct fileName we'll now lookup it using the same exact method as in the viewer itself (via a new callback-function).