Fix print-only object bitmap-image loading #46247
Merged
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.
An object element with image data that is not rendered on screen will
not initially load the image. This is because of step 2 of the spec
algorithm which states that "if the element is not being rendered,
then jump to the step below labeled fallback", skipping over step 3.5
to actually "Fetch request". [1]
If the object element is to be displayed in printing mode, the bitmap
image loading will be kicked off by the post layout call back
HTMLPlugInElement::CustomStyleForLayoutObject
. This will be too latefor the first print rendering, however it will render on subsequent
print attempts if they are made.
The proposed fix for this issue is to follow the pattern in
Document::WillPrintSoon
, which gets called before printing, toensure that bitmap images in all object elements in the doc are loaded
before printing by performing a print-mode layout that kicks off the
style or layout dependent loading.
PrintRenderFrameHelper::PrintRequestedPages
is modified to also callWillPrintSoon
so that printing from the system print dialog works asexpected. This matches
PrintRenderFrameHelper::RequestPrintPreview
which calls it for theprint preview path.
WebFrameTestProxy::StartTest
was modified to call WillPrintSoon` sothat wpt tests for print only will load the images before dumping the
print rendering pixels and match the system print dialog and print
preview paths.
[1]https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element
Bug: 41477900
Change-Id: I937d1dfff548235ef4967a625f2e0e5132b95b93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5535938
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Traian Captan <tcaptan@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1303490}