140488 2015-01-14 20:02:21 -0800 WebKit ignores HTML <base> when resolving URIs like xlink:href="#foo", in SVG within HTML 2022-07-10 12:32:44 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 http://code.google.com/p/chromium/issues/detail?id=449027 https://bugs.webkit.org/show_bug.cgi?id=189499 P2 Normal --- 1 dholbert webkit-unassigned ahmad.saleem792 ap bbrinza bfulgham rniwa simon.fraser zimmermann oldest_to_newest 1061464 0 244675 dholbert 2015-01-14 20:02:21 -0800 Created attachment 244675 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. 1161875 1 bbrinza 2016-02-03 20:34:46 -0800 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 1477303 2 simon.fraser 2018-11-10 12:17:18 -0800 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." 1881958 3 ahmad.saleem792 2022-07-10 11:42:03 -0700 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! 1881968 4 rniwa 2022-07-10 12:32:44 -0700 Yeah, this is config changed. 244675 2015-01-14 20:02:21 -0800 2015-01-14 20:02:21 -0800 testcase 1 testcase.html text/html 410 dholbert PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCiAgPGhlYWQ+DQogICAgPGJhc2UgaHJlZj0iL2ZvbyIg Lz4gICA8IS0tIFRoaXMgYmFzZSB0YWcuLi4gLS0+DQogIDwvaGVhZD4NCiAgPGJvZHk+DQogICAg PHN2ZyB2aWV3Qm94PSIwIDAgNDAwIDEwMCI+DQogICAgICA8cmVjdCBpZD0ib3JpZ2luYWwtcmVj dCINCiAgICAgICAgeD0iMTAwIiB5PSIyMCINCiAgICAgICAgd2lkdGg9IjUwIiBoZWlnaHQ9IjUw Ig0KICAgICAgICBmaWxsPSIjMjllIiAvPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8IS0t IC4uLnNob3VsZCBoaWRlIHRoaXMgZWxlbWVudDogLS0+DQogICAgICA8dXNlIHhsaW5rOmhyZWY9 IiNvcmlnaW5hbC1yZWN0IiB4PSIxNTAiIHk9IjEwIiAvPg0KICAgIDwvc3ZnPg0KICA8L2JvZHk+ DQo8L2h0bWw+DQo=