Repeated javascript insertion

[guest]

When there is some javascript code in onclick event, then xinha (or maybe gethtml plugin?) adds some frames code. Unfortunately it does not check if this code exists, so it ends like this:

<a href="#" onclick="if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}if(window.top && window.top.Xinha){return false}$('#wiecej16').toggle('slow');return false;">

Tested in Firefox for now.

[wymsy]

The problem was that FF converts the entized '&amp;'s inserted by inwardHtml back to just '&', so the regexps in outwardHtml fail to find a match. Fixed the regexps in changeset:908.

[ray]

The problem is not in inwardHTML but in transformInnerHTML, as ampersands in attributes should generally be entized. Gecko innerHTML is faulty there

[wymsy]

In theory you are right, and un-commenting line 79 in transformInnerHtml would be another way to fix this bug. However, that causes problems with all other entized characters in attributes, because regexp c[7] can't tell the difference between an '&' used in an entity and one used standalone. So '&nbsp;' becomes '&amp;nbsp;', for example. That is why line 79 was commented out.

[908] fixes this specific problem, but admittedly it is not elegant. If there is a better way, that's fine with me.

[wymsy]

Okay, you got me thinking about that regexp 07 in transformInnerHtml. I changed it to only find standalone &'s, and backed out the change from [908]. This still fixes this ticket, and it also addresses your point about entizing &'s in attributes.

[wymsy]

changeset:909

[wymsy]

and changeset:910