263834 - Some strangeness with relative links in data URI's

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041010 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041010 Firefox/0.9.1+

See the URL testcase.

The first link gets the typical layout of a link, but the second link not.
These are the two links:
<a href="">Testlink1</a>
<a href="#">Testlink2</a>

Also clicking on the first link doesn't work, because it doesn't point to the
data URI. Also middle-clicking to open the link in a new tab doesn't work.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, why does the first link end up pointing at ":"?

the second link gets no link appearance because data: does not support relative
uris, neither does it support fragment identifiers (iirc)

Comment 2

[Benjamin Smedberg]

Why are fragment identifiers a function of the protocol? Aren't they a function
of the content-type of the document?

Comment 3

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #2)
> Why are fragment identifiers a function of the protocol? Aren't they a
> function of the content-type of the document?

Because some URI types simply have no concept of fragment identifiers.  See
nsSimpleURI and the nsIURI api (which does not expose fragment identifiers,
unlike the nsIURL api).  I believe this is actually consistent with the URI RFC.
 Note that for a data: URI we treat a trailing '#whatever' as part of the data.

We keep thinking it would have been better to put fragment identifiers on nsIURI
(it would certainly make things like bug 225910 a lot less controversial).  It's
not clear to me whether that's consistent with the URI RFC and with the data:
RFC, of course.

(In reply to comment #1)
> hmm, why does the first link end up pointing at ":"?

That's a bug in nsSimpleURI, actually.  SetSpec() will allow setting an empty
spec (but it synthesizes a ':' in GetSpec()).  Right after the NS_OK return for
empty spec we check for a ':' and bail out if we don't find one.  I think we
should simply remove that |if (specLen == 0)| check.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #2)
> Why are fragment identifiers a function of the protocol? Aren't they a function
> of the content-type of the document?

each protocol handler creates the URIs for its scheme itself; and not all uri
implementations support fragments

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 6

[Darin Fisher]

Comment on attachment 161773 [details] [diff] [review]
Like so

r+sr=darin

Comment 7

[Boris Zbarsky [:bzbarsky]]

Fixed (in that the anchors now behave consistently).

Comment 8

[Martijn Wargers (dead)]

Hmm, I already had a feeling it would be fixed this way.
At least it is consistent now :-)