Side navigation
#7117 closed bug (fixed)
Opened October 06, 2010 12:41PM UTC
Closed October 07, 2010 07:05AM UTC
Last modified October 13, 2010 07:08PM UTC
In the created object returns incorrect data href attribute
| Reported by: | t_e_m_p_v_s | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.4.3 |
| Component: | attributes | Version: | 1.4.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Creating an object:
a = $('<a href="#' + url + '">' + text + '</a>');
In IE7 (maybe another IE) returns incorrect data of href attribute
href = a.attr('href');
Firefox: '#abc'
IE7: 'http://host/page#abc'
Attachments (0)
Change History (4)
Changed October 06, 2010 05:19PM UTC by comment:1
| need: | Review → Patch |
|---|---|
| priority: | high → low |
Changed October 07, 2010 06:47AM UTC by comment:2
| milestone: | 1.4.2 → 1.4.3 |
|---|
It appears that only <a> elements generated programmatically using strings exhibit this problem. Elements that are generated like $('<a>', { href: '#foo' }) work properly, as do elements that existed in the document when it was loaded.
Short of scanning all strings passed to jQuery and html for anchors and manually resetting their attributes, there is almost certainly no way that jQuery can work around this issue, as IE is irreparably modifying the href property when building elements from strings. You can see this by inspecting the generated markup (the href attribute magically becomes absolute). As a result, this is probably only going to be a documentation fix.
Changed October 07, 2010 07:05AM UTC by comment:3
| resolution: | → fixed |
|---|---|
| status: | new → closed |
Updated .html and jQuery() documentation.
Here is a live test case replicating the above ticket:
http://jsfiddle.net/addyosmani/D6MPN/
The issue does not appear to effect IE8 or IE9, but as the original submission mentions, in IE7 (and in IE6) rather than just the value of the href being set to '#abc' it is actually appending the entire base URL and treating it more like a complete anchor reference (eg. http://www.site.com/#hash).
Whilst this is something that could be corrected with special-casing, I'm flagging for an additional review and patch as the behavior mentioned in the ticket appears to be quite consistent in my testing.