Skip to main content

Bug Tracker

Side navigation

#1029 closed bug (wontfix)

Opened March 07, 2007 01:55PM UTC

Closed December 05, 2009 02:59AM UTC

Last modified March 14, 2012 08:57AM UTC

$().html() serializes href attribute in IE

Reported by: brandon Owned by:
Priority: major Milestone: 1.1.3
Component: core Version: 1.1.2
Keywords: Cc:
Blocked by: Blocking:
Description

Take the following text (snippet):

<a href="/?q=node/1" rel="bookmark" title="Permanent Link to windows">

Load into an existing DOM using the following (val.primarylinks

contains the above text):

$("#primarylinks").hide().html(val.primarylinks).show();

The text is changed to:

<a href="http://www.mydomain.com/?q=node/1" rel="bookmark"

title="Permanent Link to windows">

As you can see, the href is being changed into an absolute path. I

attempted to debug the script in vs2005 and it appears that the text

actually changes during the "clean" function at this line:

div.innerHTML = wrap[1] + s + wrap[2];

I'm no expert but it seems the assignment to innerHTML does some

processing??? Assigning to innerText does not alter the string.

Attachments (0)
Change History (8)

Changed March 07, 2007 03:03PM UTC by brandon comment:1

From Fil on Dev list:

I had a similar problem with an <a href="~fil/..."> being transformed

into <a href="%7Efil/..."> with the .html() method under FF

(consequences were that the cookies were not transmitted, so the

"action" was not "authorised"). This did not happen with .clone(), but

.clone() was crashing Safari.

So finally I resorted to:

jQuery.fn.clone2 = jQuery.browser.safari ? jQuery.fn.html : jQuery.fn.clone;

(under jquery 1.1.1 release 2); see

http://trac.rezo.net/trac/spip/changeset/8786/spip/dist/javascript/async_upload.js

Changed July 20, 2007 09:27PM UTC by brandon comment:2

description: Take the following text (snippet):\ <a href="/?q=node/1" rel="bookmark" title="Permanent Link to windows">\ \ Load into an existing DOM using the following (val.primarylinks\ contains the above text):\ $("#primarylinks").hide().html(val.primarylinks).show();\ \ The text is changed to:\ <a href="http://www.mydomain.com/?q=node/1" rel="bookmark"\ title="Permanent Link to windows">\ \ As you can see, the href is being changed into an absolute path. I\ attempted to debug the script in vs2005 and it appears that the text\ actually changes during the "clean" function at this line:\ div.innerHTML = wrap[1] + s + wrap[2];\ \ I'm no expert but it seems the assignment to innerHTML does some\ processing??? Assigning to innerText does not alter the string.Take the following text (snippet): \ <a href="/?q=node/1" rel="bookmark" title="Permanent Link to windows"> \ \ Load into an existing DOM using the following (val.primarylinks \ contains the above text): \ $("#primarylinks").hide().html(val.primarylinks).show(); \ \ The text is changed to: \ <a href="http://www.mydomain.com/?q=node/1" rel="bookmark" \ title="Permanent Link to windows"> \ \ As you can see, the href is being changed into an absolute path. I \ attempted to debug the script in vs2005 and it appears that the text \ actually changes during the "clean" function at this line: \ div.innerHTML = wrap[1] + s + wrap[2]; \ \ I'm no expert but it seems the assignment to innerHTML does some \ processing??? Assigning to innerText does not alter the string.
need: → Review
resolution: → wontfix
status: newclosed

IE serializes href and src attributes when using innerHTML ... thats it.

Changed April 16, 2009 06:02PM UTC by adamb78 comment:3

resolution: wontfix
status: closedreopened

Can you explain more on why this ticket is closed and won't be fixed? This issue is problematic for the WYMEditor project as when they try to insert images or relative hyperlinks into the editor the links get all mangled.

Changed April 21, 2009 02:20AM UTC by dmethvin comment:4

resolution: → wontfix
status: reopenedclosed

The problem lies in IE's

innerHTML
implementation. There isn't any practical and performant way for jQuery to work around this for the general case of getting and setting arbitrary HTML strings.

Here are some possible workarounds that may work in your situation: If you know you are creating an A or IMG element, create it and set its attributes explicitly rather than using an HTML string to do it. For reading, grab the elements with a selector and use

.attr()
to get the href or src attributes.

Changed May 10, 2009 07:10PM UTC by mr_lundis comment:5

resolution: wontfix
status: closedreopened

I'm sorry for reopening this ticket once again, but the proposed workaround isn't cuting it.

Setting the element attributes explicitly works fine if you're just creating single elements, but if you're dealing with larger chunks of html strings (say the whole document body) things get a bit more complicated.

Regarding possible workarounds, have you taken a look at Steve Tucker's innerXhtml?

http://www.stevetucker.co.uk/innerxhtml.htm

It's a fairly lightweight alternate to the non-standard innerHtml (about 1kb minified and gzipped). It shouldn't be that hard to adapt it for jQuery (with the authors permission of course.)

As this bug is causing a lot of people a lot of trouble I think that it's worth reconsidering fixing this. Not to mention the fact that this is one of few areas where jQuery's behaviour differs between browsers.

Also worth mentioning is that I'm a developer on the WYMeditor project, and that this issue as previously stated is casing us a lot of trouble. We could work around this issue ourselves but since a lot of people are affected an official fix would be nice.

Changed May 11, 2009 04:06AM UTC by dmethvin comment:6

The issue seems to be that 95% of the time the normal innerHTML processing is "good enough" but for the remaining 5% there's no easy workaround. Maybe we need to pull out the code in

jQuery.clean
and make it able to be overridden for cases where it's not good enough. Say,
jQuery.StringToNodes(string, documentNode)
or something like that. That would also provide a hook to fix usage in XUL per #4352.

Steve Tucker's innerXHTML code seems like it would be significantly slower than the browser's native innerHTML support--it's implementing an HTML parser in Javascript rather than C. If it could be slotted in only when it was needed, as a plugin you included to replace the standard processing, that would give you a way to produce fully pristine DOM without slowing down the 95% of cases that are fine with the default innerHTML.

Changed May 12, 2009 02:11PM UTC by mr_lundis comment:7

I did some performance testing of innerXhtml yesterday, and the difference in performance between innerXhtml and the native innerHtml is far to great indeed. It's barely noticeable a small set of elements, but when you try to insert a greater number of elements things get painfully slow.

It would seem that some kind of plugin is the way to go.

Changed December 05, 2009 02:59AM UTC by john comment:8

resolution: → wontfix
status: reopenedclosed

As noted before - any sort of solution that we could try and provide would either use too much memory or be far too slow - unfortunately this is just going to be something that we can't guarantee :-/