<use xlink:href> should not respect <base> for local references

RESOLVED DUPLICATE of bug 1357432

Status

()

Core
SVG
RESOLVED DUPLICATE of bug 1357432
3 months ago
5 days ago

People

(Reporter: rik, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
webcompat ?

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: [webcompat])

Attachments

(1 attachment)

(Reporter)

Description

3 months ago
Steps to reproduce:
Open the testcase

Actual result:
Logo is invisible

Expected result:
Logo is displayed

Works as expected: Chrome, Safari, IE 10 and 11
Works as actual: Firefox, Edge

A lot of people are running into this issue and fixing by using absolute references: https://gist.github.com/leonderijke/c5cf7c5b2e424c0061d2

I think <base> should not be used for local references aka #foo.
(Reporter)

Updated

3 months ago

Comment 1

3 months ago
Please approach w3c first if you want things to change and get agreement on a specification update. The SVG specification currently says to generate an absolute URL

https://www.w3.org/TR/SVG2/linking.html#processingURL-absolute says 

In contrast, a base element affects relative URLs in any SVG or HTML document, by altering the document base URL. 

so you'll need to get the SVG specification changed first.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → INVALID

Updated

3 months ago
Whiteboard: [webcompat]

Comment 2

3 months ago
Thanks Anthony for the report. 
The closest I find so far is 
* Document.baseURI getter doesn't return the parent document's base URL for iframes 
  https://bugs.chromium.org/p/chromium/issues/detail?id=484930

I opened another issue on the Chromium project to see what would be the comments.
https://bugs.chromium.org/p/chromium/issues/detail?id=707758

I checked in Blink (Opera), the use.baseURI is properly set on the element but is not used for deferencing the xlink:href

Comment 3

3 months ago
Created attachment 8853960 [details]
test-xlink-href-svg-base.html

Test case showing the issue.
(Reporter)

Comment 4

3 months ago
Robert: What's the best forum to bring up those issues?
Flags: needinfo?(longsonr)

Comment 5

3 months ago
https://lists.w3.org/Archives/Public/www-svg/
Flags: needinfo?(longsonr)
(Reporter)

Comment 6

3 months ago
Actually, that issue has already been brought up:

"As defined in CSS Values and Units, a fragment-only URL in a style property must be treated as a same-document URL reference, regardless of the file in which the property was declared."

https://github.com/w3c/svgwg/issues/61
https://github.com/w3c/svgwg/commit/f378b15b95841cb1297eda7b1a6a2ca2d549ee71

Reopening per spec.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 7

3 months ago
Yes and in addition, the issue was closed as WONTFIX on Chrome project because of Web Compatibility issues.

https://bugs.chromium.org/p/chromium/issues/detail?id=707758#c3
> This was changed via issue 470608 after we had attempted to implement the Gecko behavior in issue 449027 and got push-back (possibly because this "broken" behavior had existed in WebKit for quite a while.)


Given that Chrome, Safari, IE 10 and 11 works the same, I would be in favor of following the behavior of others.

Updated

3 months ago
Flags: webcompat?
(Reporter)

Comment 8

2 months ago
It has been fixed in Edge.
(Reporter)

Comment 9

2 months ago
Robert : Do you think this bug is easy enough to fix that it could be a mentored bug?
Flags: needinfo?(longsonr)

Comment 10

2 months ago
Seems to be the same issue as bug 1357432 which already has a patch. Maybe just dup to that one.
Flags: needinfo?(longsonr)

Updated

2 months ago
Status: REOPENED → RESOLVED
Last Resolved: 3 months ago2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1357432
status-firefox55: affected → fixed
You need to log in before you can comment on or make changes to this bug.