@Reporter: Please provide sample URL/test file that has <object> tag in it. This would help in further triaging of the issue.

Thanks!

It looks like the issue is with an <object> in an <iframe>. Please see this example:

iFrame page showing the issue if you try to print the content of the iframe:
https://dealers.virtualyard.com.au/debug/chrome.html

The content of the iframe does print correctly when not hosted within an iframe:
https://dealers.virtualyard.com.au/debug/example.html

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Reporter@ Thanks for the update.

Able to reproduce the issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 68.0.3417.2 and Beta 67.0.3396.30 as per comment #3.
On navigating to the link - https://dealers.virtualyard.com.au/debug/chrome.html, and clicking on Print button, cannot observe svg content on the Print preview page.

Marking this issue as Untriaged and adding 'Needs-Bisect' label. Will provide the bisect info soon.

Thanks..

// Adding to comment #5.

Bisect Information:
===================
Good Build: 66.0.3359.49
Bad Build : 66.0.3359.52

Unable to execute the per-revision bisect script,as this is regressed in branch builds. Hence below is the Manual Changelog URL from omahaproxy:

https://chromium.googlesource.com/chromium/src/+log/66.0.3359.49..66.0.3359.52?pretty=fuller&n=10000

From the above Changelog, suspecting the below change:
Reviewed-on:https://chromium-review.googlesource.com/976442

erikchen@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable for M-66 as this is a recent regression. Please feel to remove if this is not applicable.

Thanks.

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

I've confirmed that the problematic lines are:

"""
void Document::SetPrinting(PrintingState state) {
...
  documentElement()->LazyReattachIfAttached();
...
}
"""

I guess that the method is not idempotent. svg content probably needs async passes of the main message loop to render correctly.

As a workaround, we could refrain from calling LazyReattachIfAttached() if the owner is not display none. This still leaves the edge case of a display: none iframe with SVG contents that won't render correctly...

+ weili - any idea why SVG elements wouldn't print correctly and/or why LazyReattachIfAttached() isn't idempotent?

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

As this is regressed in M66 stable and we're very close to M67 stable promotion,  we won't consider this as M67 Stable blocker. Pls let us know ASAP if there is any concern here. Thank you.

This problem is specific to <object> tags. 

This fails to print correctly:
<object width="909" height="1286"                                           
data="https://pro.virtualyard.com.au/popups/NSW-Form5/1/1.svg" type="image/svg+xml"></object>

But this prints correctly:
<img src="https://pro.virtualyard.com.au/popups/NSW-Form5/1/1.svg">    

Repro steps #1:

1) Open network devtools panel.
2) Load the iframe URL from c#3
3) Open print preview.

Notice: (3) triggers a second network request for 1.svg. There is also a brief flash of the svg on the main page [not the print modal dialog].

Repro steps #2:

test7.html:
<iframe id="printPage" src="test6.html" width="100%" style="min-height:700px;" frameborder="0"></iframe>   

test6.html:
<object width="909" height="1286" data="https://pro.virtualyard.com.au/popups/NSW-Form5/1/1.svg" type="image/svg+xml"></object>   

1) Open network devtools panel.
2) Navigate browser to test7.html.
3) Open print preview.
4) Close print preview.

Starting from (3), I observe a stream of successful network requests for the 1.svg resource [~1-2 a second].
Even after (4), the stream of network requests continues!

+ schenney

Could I get a consult here? It appears that in the second set of repro steps in c#15, a single call to documentElement()->LazyReattachIfAttached(); from Document::SetPrinting causes an infinite stream of network requests. :(

This seems more like a loader issue. What if you force a stack trace from the load request to see where it is coming from?

I think that's in DocumentResource::FetchSVGDocument

https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/core/loader/resource/document_resource.cc?rcl=e0a5855513286b1318bebf5540e5c3db0633e1b8&l=42

This sounds like the old problem of losing the frame during reattach... (fairly sure there's an existing bug about it, but couldn't find it just now. Issue 703086 sounds similar to second part of c#15.)

The loading will start at:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/html_frame_owner_element.cc?type=cs&l=354

(DocumentResource::FetchSVGDocument is only for resource documents.)

More updates:

DocumentResource::FetchSVGDocument is never called because this isn't an <svg> element. Instead, we're seeing RawResources being fetched for the Document.

The order of events appears to roughly be:

1) LocalFrameView::PerformLayout
...blink::LayoutEmbeddedObject::UpdateLayout() 
...blink::LocalFrameView::AddPartToUpdate
2) LocalFrameView::ScheduleUpdatePluginsIfNecessary
3) HTMLObjectElement::UpdatePluginInternal
4) HTMLPlugInElement::RequestObjectInternal
5) HTMLFrameOwnerElement::LoadOrRedirectSubframe
...
"""
  ContentFrame()->Navigate(GetDocument(), url, replace_current_item,          
                              UserGestureStatus::kNone);           
"""

When the navigation completes, this whole chain of events is triggered again. More details soon.

Issue 646427 was the existing bug (about reload-on-reattach) I was thinking about.

There are two problems: The EmbeddedContentView is unnecessarily (?) being destroyed. The EmbeddedContentView is never being reset.

1) Document::SetPrinting calls LazyReattachIfAttached. 
2) In HTMLPlugInElement::DetachLayoutTree, the embedded content view is destroyed because OwnedPlugin() returns nullptr, even though OwnedEmbeddedContentView() does not.

I wonder if we should be generalizing SetPersistedPlugin() to also apply to other types of embedded contents?

3) When just loading the page, the EmbeddedContentView is set by the following call stack:
> content::RenderFrameImpl::OnSwapOut
> blink::WebFrame::Swap
> blink::WebRemoteFrameImpl::InitializeCoreFrame
> blink::RemoteFrame::CreateView

This doesn't happen when the page ends up in the reload loop.

Yes, persisting the EmbeddedContentView for cases other than when it's a PluginView is likely the way to go here. (I'd expect there to be a string of problems to follow though.)

I confirmed that opting out of site isolation via #site-isolation-trial-opt-out prevents the infinite stream of network requests. I'll file a separate bug for that.

Filed: https://bugs.chromium.org/p/chromium/issues/detail?id=843591

Sounds related to issue 771757.  HTMLFrameOwnerElement should retain its EmbeddedContentView regardless of attach/detach.

I talked with erikchen, and my understanding is problem #1 (not persisting the embedded content view) is not oopif specific.

HTMLPlugInElement is a bit weird in that it uses AttachLayoutTree/DetachLayoutTree to manage its embedded content view, unlike HTMLFrameElementBase which uses inserted/removed from document to manage it...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bb8bde5753009711d89b9608921b6f6b48e9673

commit 0bb8bde5753009711d89b9608921b6f6b48e9673
Author: Erik Chen <erikchen@chromium.org>
Date: Thu May 17 20:11:05 2018

Fix HTMLObjectElement printing in iframes.

LazyReattachIfAttached is not idempotent. Calling it will cause
HTMLObjectElements to discard their contents, which must be asynchronously
regenerated. Avoid calling it if we think it won't have an effect.

This still leaves the edge case of HTMLObjectElements in display:none iframes
not printing correctly.

Bug:  838760 
Change-Id: I5d4fdbfe7e2710b824c3ecc446385fae09cbc7c7
Reviewed-on: https://chromium-review.googlesource.com/1053882
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559652}
[add] https://crrev.com/0bb8bde5753009711d89b9608921b6f6b48e9673/third_party/WebKit/LayoutTests/printing/iframe-svg-in-object-print-expected.txt
[add] https://crrev.com/0bb8bde5753009711d89b9608921b6f6b48e9673/third_party/WebKit/LayoutTests/printing/iframe-svg-in-object-print.html
[add] https://crrev.com/0bb8bde5753009711d89b9608921b6f6b48e9673/third_party/WebKit/LayoutTests/printing/resources/circle.svg
[add] https://crrev.com/0bb8bde5753009711d89b9608921b6f6b48e9673/third_party/WebKit/LayoutTests/printing/resources/iframe-subframe-svg-in-object.html
[modify] https://crrev.com/0bb8bde5753009711d89b9608921b6f6b48e9673/third_party/blink/renderer/core/dom/document.cc

Pls update bug with canary result tomorrow. Thank you.

Able to reproduce this issue on Windows 10, Mac OS 10.13.3 and Ubuntu 14.04 on the reported version 66.0.3359.139 and the issue is fixed on the latest Canary 68.0.3434.0 as per comment #3.

On navigating to the link - https://dealers.virtualyard.com.au/debug/chrome.html, and clicking on Print button, can observe svg content on the Print preview page.
Attached is the screen shot for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 838760-M68-CL.PNG 250 KB

	838760-M68-CL.PNG 250 KB View Download

The NextAction date has arrived: 2018-05-18

Since this regressed in M-66, going to refrain from merging a fix to M-67. The fix will be in M-68.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-67 label, otherwise remove Merge-TBD label. Thanks.

While the problem pointed out in the opening comment is solved, this will still be an issue for display:none iframes with svg content in <object> tags that are printed. A full solution would involve something like what was proposed in c#22. That being said, that will likely have side effects, and is not something I'm particularly inclined to tackle at this moment..

This is not M67 stable blocker, so we're not taking this merge in per comment #35. Hence, removing "Merge-TBD" label. Thank you.