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

Fix print-only object bitmap-image loading #46247

Merged
merged 1 commit into from
May 20, 2024

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented May 14, 2024

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 late
for 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, to
ensure 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 call
WillPrintSoon so that printing from the system print dialog works as
expected. This matches
PrintRenderFrameHelper::RequestPrintPreview which calls it for the
print preview path.

WebFrameTestProxy::StartTest was modified to call WillPrintSoon` so
that 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}

@chromium-wpt-export-bot chromium-wpt-export-bot changed the title Fix print only object bitmap image loading Fix print-only object bitmap-image loading May 17, 2024
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-5535938 branch 4 times, most recently from edd13d1 to 7ced1d7 Compare May 18, 2024 02:36
@chromium-wpt-export-bot chromium-wpt-export-bot marked this pull request as ready for review May 20, 2024 22:55
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 late
for 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, to
ensure 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 call
`WillPrintSoon` so that printing from the system print dialog works as
expected. This matches
`PrintRenderFrameHelper::RequestPrintPreview` which calls it for the
print preview path.

`WebFrameTestProxy::StartTest` was modified to call WillPrintSoon` so
that 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}
Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot merged commit e97b0ff into master May 20, 2024
18 checks passed
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-5535938 branch May 20, 2024 23:12
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.

None yet

4 participants