Bug Tracker

Opened 15 years ago

Closed 15 years ago

#4125 closed bug (wontfix)

href changing in IE

Reported by: john Owned by:
Priority: minor Milestone: 1.3.2
Component: core Version: 1.3.1
Keywords: Cc:
Blocked by: Blocking:


When you attempt to change the href of an anchor in IE (of which the text value is identical to the href) the text value will be changed, as well. Some workaround should be provided for this.

Change History (4)

comment:1 Changed 15 years ago by shadedecho

Just as an fyi, it seems it's IE actually comparing the underlying html inside the <a> tag to see if that identically matches the href url. Even if the rendered text is the same, but the html is different (for instance the / character replaced with an html entity, or some part of the link text is wrapped in a <span> or <b>, etc), IE will not mess with things. So the proper check to see if IE needs to be quirk-fixed is something like: $(this).html()===$(this).attr("href")

Two thoughts on a workaround:

  1. Prevent IE from doing its dirty work by first breaking the exactness between the two properties. You could insert/append some invisible html entity (like <wbr> for instance?) to the html of the link first, then change the href, then remove the shim. That should fix the quirk, but also prevent any layout re-rendering "flashes" or other ugliness to users, giving a better user experience it would seem.
  1. Or, you could let IE do its work and then clean it up. Thankfully IE lets you change the html right back after it messes with things. So, you can first capture/save the innerHTML of the link, then change its href, then change it's html right back. For good measure, you also temporarily set visibility:hidden on it while the flip occurs, to cut down on layout re-rendering "flashes". Maybe display:none is better, but then it moves surrounding content temporarily in to the real-estate taken up by the original link, causing the undesired layout-rerendering.

comment:2 Changed 15 years ago by shadedecho

Follow up: I tried method #1 on my site and it works just great. Here's the code I used:


comment:3 Changed 15 years ago by brandon

need: ReviewTest Case

comment:4 Changed 15 years ago by brandon

Resolution: wontfix
Status: newclosed

Should the core really try to fix this? Seems like such an edge case with a very simple workaround. Not even sure how this would fit into $.support.

I think this is better just documented.

Note: See TracTickets for help on using tickets.