Unable to triage this issue from TE-End, adding "TE-NeedsTriageHelp" for further triage.

I guess I'll have to try to bisect this M-54 regression. Old regressions like this are not regressions for tracking purposes.

At work we're hitting the same problem with a react application. Initial render is fine, but after route navigation, some icons are not displayed. Whenever that happens the shadow dom of the `<use>`-Element is empty.

Based on the various tidbits of information present here I'd guess that there is some relation to  issue 470608 . Something to check for then would be if the <use> 'href' is rewritten and used in combination with a <base>.

In our case we don't use the `<base>` tag. After a reload the icon is visible again.

Bisect (after mammoth effort to get things set up on a Google workstation) to:
https://chromium.googlesource.com/chromium/src/+/91e189ad391cd78854f71f816c08c08e7bc991a4

fs@, that's "Resolve URL/target reference at a single point in SVGUseElement". And yes, it is related to 470608.

Reporters, what is the behavior on Edge?

I have tested other browsers and Edge seems to work.

This works OK on:
FIrefox 54 stable
Firefox 55 Beta
Edge 15
Edge 14
IE 11
IE 10
Safari 10.1.1

Looks like the primary cause for this is the pushState - being used after the 'href' is (re)set. Setting/updating the 'href' will resolve the URL in Blink. The URL will then _not_ be re-resolved until it changes again. Other browsers do things differently here: Gecko seems to re-resolve at paint (??? fails at first, but then forcing a repaint unbreaks it [2]), but not at pushState. Edge appears to (re)resolve at layout (flushing any pending layout after setting 'href' appears to "break" the element reference.) Not particularly well-speced this...

It would seem to be less fragile (for content) to reset the 'href' after the pushState has happened (any better hook to use in frameworks here?) In Blink, just using a plain fragment-reference ("#icon-list" etc) would suffice though.

I guess we could defer the resolution until just prior to stamping out the shadow tree. (Doesn't seem great for certain types of external references though, but hopefully those won't be too common...)

[1] Edge and Gecko appear to do so as well based on the network requests they issue in my minimized TC (attached).
[2] IIRC though, Gecko re-resolves on changes to the document base URL.

Deleted: minimized.html 440 bytes

minimized.html 440 bytes View Download

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

commit eae372c09940a9b140b7b127cbe20b52704aa03e
Author: Fredrik Söderquist <fs@opera.com>
Date: Wed Aug 30 12:23:58 2017

Don't rely on the cached 'local' flag when resolving <use> target

Since the document URL can change between a <use> 'href' is set, and the
actual element reference is resolved (looked up by id), the notion of
being "local" to the document can change during this window as well.
To avoid this, we need to re-evaluate the "is local" state before
resolving the element reference. This appears to match what other UAs
are doing (but they could/do differ in other ways.) Keep the cached
"is local" state and use where applicable to avoid the full URL compare.

Bug:  749855 
Change-Id: Ibbe9b1fb7e37f86b57f775d288203fbd9b3d5f4e
Reviewed-on: https://chromium-review.googlesource.com/641459
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498433}
[add] https://crrev.com/eae372c09940a9b140b7b127cbe20b52704aa03e/third_party/WebKit/LayoutTests/http/tests/svg/use-url-change-after-href-change-expected.html
[add] https://crrev.com/eae372c09940a9b140b7b127cbe20b52704aa03e/third_party/WebKit/LayoutTests/http/tests/svg/use-url-change-after-href-change.html
[modify] https://crrev.com/eae372c09940a9b140b7b127cbe20b52704aa03e/third_party/WebKit/Source/core/svg/SVGUseElement.cpp
[modify] https://crrev.com/eae372c09940a9b140b7b127cbe20b52704aa03e/third_party/WebKit/Source/core/svg/SVGUseElement.h

@c#4, could you check if this fixes your use case too, and if not file a new bug?

@c#11 Thanks for your work on this. Not sure where I can test these changes. Just tried out with latest Chrome Canaray and the issue still persists for us. I'll file an issue once I manage to create a minimal reproducable setup