Fix print-only object bitmap-image loading
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}