Bug 140488 – WebKit ignores HTML <base> when resolving URIs like xlink:href="#foo", in SVG within HTML

• Component: SVG
• Status: RESOLVED CONFIGURATION CHANGED

[Daniel Holbert]

Created attachment 244675 [details]
testcase 1

STEPS TO REPRODUCE:
  View attached testcase.
(which is a slightly tweaked version of https://bug1121708.bugzilla.mozilla.org/attachment.cgi?id=8549260 )

EXPECTED RESULTS
  One blue rect.

ACTUAL RESULTS:
  Two blue rects.

Please use labels and text to provide additional information.
  The second blue rect is from a <use> element, with xlink:href="#original-rect". The problem is, there's a <base> element, which is supposed to set the base URL to be used when resolving relative URLs in attributes in the document (including this xlink:href attribute), as described at https://html.spec.whatwg.org/multipage/semantics.html#the-base-element

So, the xlink:href="#original-rect" URL *should* be interpreted as "/foo#original-rect", which doesn't resolve to anything (in this case), so nothing should show up.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 for a discussion of how this works in Firefox. I'm filing this bug here in the hopes of getting interoperability on this.


NOTE: I filed this on Blink here: https://code.google.com/p/chromium/issues/detail?id=449027

VERSION INFO:
WebKit version tested: Midori version 0.4.3, which reports itself as using "WebKitGTK+" version "1.10.1 (2.4.6)" (in about:version) 
I also tested Safari 8 on OS X Yosemite.  Same results in each. (and in Chrome)

Firefox matches my EXPECTED RESULTS.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 for discussion on Firefox's behavior.

[[e-mail]]

Blink bug was fixed and now the pages with <base> work interoperably in Edge, Chrome (canary) and Firefox, but not Safari/WebKit

This was resolved last August during Paris face to face SVG WG meeting - https://www.w3.org/2015/08/25-svg-minutes.html#item08

[Simon Fraser (smfr)]

This behavior was changed via https://github.com/w3c/svgwg/issues/61. CSS Values now has <https://drafts.csswg.org/css-values/#local-urls>:

"When matching a url() with the local url flag set, ignore everything but the URL’s fragment, and resolve that fragment against the current document that relative URLs are resolved against."

[Ahmad Saleem]

I am unable to get "Expected Result" based on attached test case in Safari 15.5 on macOS 12.4 and Safari Technical Preview 148 but the actual results (of two blue rects) is now consistent with other browsers (Chrome Canary 105 and Firefox Nightly 104).

Further, Comment 02 mentioned an update in Web-Spec, should this be marked as "RESOLVED INVALID" or "RESOLVED CONFIGURATION CHANGED"? Thanks!

[Ryosuke Niwa]

Yeah, this is config changed.