In bad builds the picture blinks on every reload.
In good builds it doesn't.

Bisect info: 470489 (good) - 470495 (bad)
https://chromium.googlesource.com/chromium/src/+log/5730d628..27217b88?pretty=fuller
Suspecting r470490 = 91088a195969f5af61f404c9f02edc622cbe373a = https://crrev.com/2873623002 by yhirano@chromium.org
"Add Field Trial Testing Configuration for MojoLoading"
Landed in 60.0.3096.0

Confirmed by disabling chrome://flags/#enable-mojo-loading and observing the bug is gone (I had to clear the browser cache too).

That commit may have exposed some already existing issue - possibly by changing the buffering or timing (of layout). At least it seems that the 64k (byte) boundary in the is document is significant - that's where the nodes referenced by the <use> that produces the "Flutter" part of the text resides, with the 64k cutoff being within the element that produces the "u". Editing the document moves the issue somewhere else or hides it completely.

I suspect that https://jsfiddle.net/ojprsh7m/ illustrates the same issue, but in a slightly more minimal way.

(+yhirano mostly as a FYI.)

#3, you're right, here's another bisect with forced mojo-loading via --enable-features=LoadingWithMojo 

Bisect info: 457263 (good) - 457272 (bad)
https://chromium.googlesource.com/chromium/src/+log/f454af4e..8258b1c5?pretty=fuller
Suspecting r457269 = 9eadabae1de0cb22725450596fe324f03dd63b92 = https://crrev.com/2725133002 by rockot@chromium.org
"Mojo: Armed Watchers"
Landed in 59.0.3043.0

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

commit a8014bf1bc9b0c1c4b709702f404a84c5cc948cd
Author: Fredrik Söderquist <fs@opera.com>
Date: Mon Dec 18 16:48:54 2017

[PE] Invalidate <use> instances even when mutating from the parser

When a layout is triggered when the parser is interrupted, an instance
tree can be built for a <use> that references a subtree that contains
the insertion point of the parser. This <use> instance (or instances)
would then not be invalidated when the parsing resumed.

Invalidate instances of an element when its children changes even when
the mutation originates from the parser. (This condition was added in
3c2310f2e9e0947e390c25911b61cfe69e162a78 without further explanation
"Only invalidate SVGElementInstances when !changedByParser is set.". Due
to the lazyness of the shadow tree/instance rebuilding this will
hopefully not regress performance.)

Bug:  794594 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I58f3a74ef9812503c0111d3564dad8ee3527d27b
Reviewed-on: https://chromium-review.googlesource.com/832386
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#524726}
[add] https://crrev.com/a8014bf1bc9b0c1c4b709702f404a84c5cc948cd/third_party/WebKit/LayoutTests/svg/custom/use-child-change-by-parser-expected.html
[add] https://crrev.com/a8014bf1bc9b0c1c4b709702f404a84c5cc948cd/third_party/WebKit/LayoutTests/svg/custom/use-child-change-by-parser.html
[modify] https://crrev.com/a8014bf1bc9b0c1c4b709702f404a84c5cc948cd/third_party/WebKit/Source/core/svg/SVGElement.cpp

Still a potential "QoI" issue lurking (timing of layout+paint), but the incorrect rendering should be fixed.