Able to reproduce the issue on Windows 10, mac 10.13.6 and Ubuntu 17.10 using chrome reported version #70.0.3538.110 and latest canary #72.0.3621.0.

Bisect Information:
=====================
Good build: 70.0.3525.0
Bad Build : 70.0.3526.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/41b5b795832626a12a410e1956028a8d53b8e163..f6a6fa6c2133597586b8e698fe771d71d44a2f33

From the above change log suspecting below change
Change-Id: Ia1a999072e87cc32fbde1bb70f8bb39e9b3053a7
Reviewed-on: https://chromium-review.googlesource.com/1178622

lukasza@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-70 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

This is regressed in M70, not a blocker for M71 stable. Pls target fix for M72.

I can confirm that the issue repros with --site-per-process and doens't repro with --disable-site-isolation-trials at ToT (r610853).

I see that the following callstack repeats over and over again:

#1 0x7fb9ac5943f7 content::RenderFrameProxy::Navigate()
#2 0x7fb9a5ddd54b blink::RemoteFrameClientImpl::Navigate()
#3 0x7fb9a5ddc360 blink::RemoteFrame::Navigate()
#4 0x7fb9a5ddc0ea blink::RemoteFrame::ScheduleNavigation()
#5 0x7fb9a5f2ebc8 blink::HTMLFrameOwnerElement::LoadOrRedirectSubframe()
#6 0x7fb9a5f4e87f blink::HTMLPlugInElement::RequestObjectInternal()
#7 0x7fb9a5f50430 blink::HTMLPlugInElement::RequestObject()
#8 0x7fb9a5f4a08b blink::HTMLObjectElement::UpdatePluginInternal()
#9 0x7fb9a5f4f6c2 blink::HTMLPlugInElement::UpdatePlugin()
#10 0x7fb9a5db1bee blink::LocalFrameView::UpdatePlugins()
#11 0x7fb9a5da7170 blink::LocalFrameView::UpdatePluginsTimerFired()
#12 0x7fb9a4468d53 blink::TimerBase::RunInternal()

The browser-side commits the navigation in another process, but this doesn't stop the callstack above from occurring again and requesting yet another navigation.  I don't understand what mechanism is responsible from repeatedly trigerring that callstack above (i.e. I don't understand if the looping involves the OOPIF, or if it happens entirely withing the file: renderer that hosts the test.html repro file).

Based on the fact that this repros in presence of OOPIFs, I am guessing that this regressed back in M67, when shipping site-per-process to the stable channel.  I think this also means that this is not really a ReleaseBlock-Stable.

ekaramad@, could you please take a closer look (since AFAIK you've worked on OOPIF-vs-<object> interactions in the past).

Also adding dcheng@ and schenney@ who I think might be familiar with this area of code.

To expand what I wrote in #c5 - this is the navigation request made via remote frame proxy:

[106244:106244:1126/090424.739325:ERROR:render_frame_proxy_host.cc(307)] RenderFrameProxyHost::OnOpenURL; params.url = https://upload.wikimedia.org/wikipedia/commons/c/cc/Cloudy03.svg; site_instance_->GetSiteURL() = file:///; current_rfh->GetSiteInstance()->GetSiteURL() = https://wikimedia.org/

This seems to be a duplicate of some other bug I am trying to find. I'd guess this is because we dispose the EmbeddedContentView when |data| changes (which is a RemoteFrameView) but never put something back in. I will look for the other bug and confirm.

If that is the case, something like this CL should fix it (although it is admittedly not the proper fix):
https://chromium-review.googlesource.com/c/chromium/src/+/1341137

Couple of notes:

1- The bug does not repro on any URL. I shouldn't at least when one of of the URLs is same-origin because that leads to a WebFrame::Swap and reinserting the frame view.

2- For cross-process navigations it will look frozen but the actual underlying frame loads. It also does not necessarily always lead to infinite loop for navigation. Going form "https://wikipedia.org" to "https://build.chromium.org" there is no infinite loop, but going to a cross-origin SVG I see an infinite loop for loading the image.

3- The patch in comment #9 fixes the issue.

 Issue 838008  has been merged into this issue.

All - I'm the creator of  Issue 838008  (Chrome runs load event multiple times when changing the data URL) and wondering if there is a date for this issue to be fixed? Our team have a commercial product that relies on this feature and although we can apply a workaround it does measurably slow our application which relies on many <object> tags and the JS in the load event. Our team can help debug but we only have 1 guy who has basic C++ skills.