392756 - [1.8 branch] node.getAttribute and node.href return strings with different escaping

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Mike Kaply [:mkaply]]

When using JavaScript to access the href of an anchor, accessing .href directly returns a string that has been escaped, whereas accessing the href via getAttribute is not.

there should be consistency between the return of these two values.

Testcase at URL.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

This is, IMO, invalid. getAttribute returns the string value in DOM, .href (according to DOM Level 2 HTML) returns "The absolute URI [IETF RFC 2396] of the linked resource".
If you modify the test a bit, you'll notice that .href does return the absolute 
value (and .getAttribute still just the string value).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep.  This is invalid.

Comment 3

[Mike Kaply [:mkaply]]

What am I supposed to do with what I get back from the href then? decodeURIComponent doesn't work on it, and escape is deprecated.

How do I get it back to a real string?

Comment 4

[Jesse Ruderman]

decodeURIComponent works fine on the value I get from document.links[0].href.  Tested with Mac trunk.

Comment 5

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

if decodeURIComponent doesn't work, that's the bug you should file.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> What am I supposed to do with what I get back from the href then?

What do you mean by "do"?  That's the value we'll send to the server.  You can do anything you want with it...

> decodeURIComponent doesn't work on it,

How exactly?  Never mind that in this case you probably want decodeURI instead.

> How do I get it back to a real string?

What do you mean by "real string"?  If you want the attribute value, then just get the attribute value.  If you want the URI, you can get that via .href.

Maybe I'm missing what the problem is, exactly?

Comment 7

[Mike Kaply [:mkaply]]

I analyzed this wrong. i narrowed my testcase too much.

The bug is with decodeURI on iso-8859-1 pages.

See:

bug 392838