Thanks for the report!  Confirmed that when I follow the repro steps, I get a crash in a subframe on Linux ToT and Mac canary 69.0.3479.0, with --site-per-process enabled.

On Linux with dcheck_always_on, I hit the following, which looks the same as  issue 859596 :

[186715:186715:0713/131836.424211:ERROR:surface_manager.cc(494)] Old/orphaned temporary reference to SurfaceId(FrameSinkId(13, 6), LocalSurfaceId(2, 1, 908F...))
[1:1:0713/131837.186565:FATAL:local_frame_view.cc(1751)] Check failed: false. 
#0 0x7f6476bfbd3c base::debug::StackTrace::StackTrace()
#1 0x7f6476b261fb logging::LogMessage::~LogMessage()
#2 0x7f646e9db740 blink::LocalFrameView::SetNeedsLayout()
#3 0x7f646e9deed7 blink::LocalFrameView::SetLayoutSize()
#4 0x7f646ea35cbb blink::WebFrameWidgetImpl::Resize()
#5 0x7f64748f0170 content::RenderWidget::ResizeWebWidget()
#6 0x7f64748f06b7 content::RenderWidget::SynchronizeVisualProperties()
#7 0x7f64748ed3b0 content::RenderWidget::OnSynchronizeVisualProperties()
#8 0x7f64748e87be _ZN3IPC8MessageTI40ViewMsg_SynchronizeVisualProperties_MetaNSt3__15tupleIJN7content16VisualPropertiesEEEEvE8DispatchINS4_12RenderWidgetES9_vMS9_FvRKS5_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#9 0x7f64748e825a content::RenderWidget::OnMessageReceived()
#10 0x7f6475165bff IPC::MessageRouter::RouteMessage()
#11 0x7f6475165b3a IPC::MessageRouter::OnMessageReceived()
#12 0x7f64739f114c content::ChildThreadImpl::OnMessageReceived()
#13 0x7f647514d311 IPC::ChannelProxy::Context::OnDispatchMessage()

On Mac, my crash ID was a9afc87ed676c78a, and we crash on a CHECK(!text.NeedsLayout()) in blink::SVGInlineTextBox::ConstructTextRun, deep inside blink::LocalFrameView::PaintTree().

CC'ed folks - anyone willing to investigate further on the site isolation side?

We will be deploying a workaround to bypass the issue so the original steps to reproduce the problem will stop replicating the crash.

I have created another code snippet that replicates the problem at https://loader.frames.news/observador.pt.chrome-issue-863427.js

The new steps to reproduce the problem are:
- Navigate to https://observador.pt/2018/07/13/de-sem-abrigo-nas-ruas-de-lisboa-para-a-capa-da-vogue-portugal/
- Open the inspector (F12)
- Go to the console and copy paste the javascript code of https://loader.frames.news/observador.pt.chrome-issue-863427.js

Sorry for the change.

Additional info we gathered while trying to bypass the issue:

The bug seems to occur when the `x` or `y` attribute of a ´text´ element inside a svg is changed. 
This attribute change is triggered from inside a resize event callback.
The javascript code responsible for this change runs inside the iframe context.
We change other attributes of other elements without any influence (the problem seems to be localized only in text elements).

Hope this info helps.

Fady, would you be able to triage this further?  I wonder if you might know more from your work on SynchronizeVisualProperties, and whether the "Old/orphaned temporary reference to SurfaceId" error that I observed when trying to repro might be related.

This is a layout bug not a surface sync bug. I'm assigning to chrishtr@ for triage.

I can repro on Windows as well using the steps in comment 2 (though not every time-- sometimes it takes a few attempts).  Example crash ID from Windows Canary 69.0.3494.0: 013c3f134ce638d0.

Once we know more about what it takes to fix, we can decide if a merge to M68 is plausible or not.

For reference, the crash signature is blink::SVGInlineTextBox::ConstructTextRun, with a pretty deep stack involving a lot of paint and layout.  Updating summary accordingly.

The DCHECK is due to an uninitialized data issue related to frame throttling,
which affects only debug builds. I will fix it. Not sure what the actual 
non-debug crash is though, still looking.

Other than that DCHECK, I cannot reproduce on Mac Canary, Linux Dev or
Linux ToT with --site-per-process.

Comment 8: Are you using the steps in comment 2?  I get a crash (af76c2fdaa273ee7) there on Mac Canary 69.0.3495.0, when I paste the code from https://loader.frames.news/observador.pt.chrome-issue-863427.js into the DevTools console on https://observador.pt/2018/07/13/de-sem-abrigo-nas-ruas-de-lisboa-para-a-capa-da-vogue-portugal/.

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

commit 224ba0fb28cbf12ee775e53889380c5f218eac42
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Wed Jul 18 20:53:26 2018

Fix DCHECK, which was happening due to un-initialized variables
for throttled subframes.

needs_forced_compositing_update_ could have been set, in cases
when a style update in a throttled frame caused destructive mutations
of compositing state that must be cleaned up or result in stale
pointers from cc.

needs_forced_compositing_update_ forces off throttling for a frame up to
the compositing step, for this reason. It is cleared during the compositing
update step. This means that ShouldThrottleRendering may return true after
this step when it returned false before.

Bug:  859596 , 863427 

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Idc4857b9f4a465f602e3bcc12a76e48d394a2689
Reviewed-on: https://chromium-review.googlesource.com/1141106
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576202}
[modify] https://crrev.com/224ba0fb28cbf12ee775e53889380c5f218eac42/third_party/blink/renderer/core/frame/local_frame_view.cc
[modify] https://crrev.com/224ba0fb28cbf12ee775e53889380c5f218eac42/third_party/blink/renderer/core/paint/paint_layer.cc

The patch in comment 10 does not actually fix any crash, it just fixes the
DCHECK.

@creis: can you still reproduce? Can you do so on Linux? I have no luck so far.

Huh, for whatever reason, I'm not seeing the crash on Linux, either 67.0.3396.99 or tip of tree with your patch applied.  I do still see it on Mac (and Windows), as noted in comment 9.

I can't reproduce on Mac Canary, or ToT Mac code...

I could reproduce this in devchannel at 69.0.3493.3 and I cannot reproduce this in devchannel at 69.0.3497.12. Here's the changelog:
https://chromium.googlesource.com/chromium/src/+log/69.0.3493.0..69.0.3497.0?pretty=fuller&n=10000

I don't know how much I trust that range but it's a start. We could try bisecting since this crashes in release builds. "Remove browser-initiated navigations from WebContentsObserver::DidGetUserInteraction." is a possible patch.

-> back to you Charlie

Interesting!  I can no longer repro the crash anymore either, on either Windows or Mac.  I ran a bisect and got this:
----
You are probably looking for a change made after 576201 (known good), but no later than 576202 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/775612b8280bc78b561e54811576035d4e53fe6d..224ba0fb28cbf12ee775e53889380c5f218eac42
----

That's chrishtr@'s r576202 from comment 10, which landed in 69.0.3496.0.  Chris, does that make sense that your CL might have fixed real behavior as well and not just a DCHECK?  I'll mark it fixed per that CL, anyway.

As for merge to M68, it looks like this was the #211 renderer crash on M67 stable, and it's currently the #294 renderer crash on 68.0.3440.75.  That suggests to me that it's probably not needed for a post-stable merge, and we can wait for M69.  CC'ing Abdul for FYI, or in case he'd like to pick up the fix anyway.

Thanks Chris!

It does not make any sense to me...I looked just now and I can't see a way this 
CL could possibly fix the bug. Super weird. Maybe one of those methods to check
dirty bits somehow has a side-effect?

It seems to correlate with the crash reports stopping, at any rate:
https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27blink%3A%3ASVGInlineTextBox%3A%3AConstructTextRun%27#-property-selector,productname:1000,productversion:100,-magicsignature:50,-magicsignature2:50,-stablesignature:50,-magicsignaturesorted:50

Last reported crash was in 69.0.3495.0.  

(Though, there seem to be some more recent reports from Android with unexpected "version" numbers like 578958 as in crash/752b6f1b420f2f42, which look more like commit positions from M70.  Hard to tell how to interpret that, though.)