Re: [jQuery] Fix for IE XML nested each issues (Bug #164)
Peter Woods schrieb: What other problems did the second fix (or hack, as it's more aptly called) cause? Just wondering what sort of things I should test as I try and find a better solution to it. Any suggestions for accomplishing the same behavior for the second fix without resorting to an IE specific hack? After adding your hack, the test suite produced tons of errors. I think it would be best if you just add the fix in your version and run the test suite against it. With FF and FireBug installed, it should be quite obvious what exactly is breaking. It's way to much to describe it here. -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Fix for IE XML nested each issues (Bug #164)
After adding your hack, the test suite produced tons of errors. I think it would be best if you just add the fix in your version and run the test suite against it. With FF and FireBug installed, it should be quite obvious what exactly is breaking. It's way to much to describe it here. I just made some additional fixes/additions and everything seems to be working fine now. Thanks for your help, Peter. --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Fix for IE XML nested each issues (Bug #164)
Peter Woods schrieb:
The fix is quite simple, as far as I can tell... simply replace the
line in question with this:
// Handle HTML strings
var m;
if (typeof a == string) m = /^[^]*(.+)[^]*$/.exec(a);
This works and is now in SVN, tested.
} else if ( jQuery.browser.msie elem.getAttribute(name) !=
undefined ) {
if ( value != undefined ) elem.setAttribute( name, value );
return elem.getAttribute( name );
This caused quite a lot of other problems
contains: ((a.firstChild
a.firstChild.nodeValue)||a.innerText||a.innerHTML).indexOf(m[3])=0,
Is added to SVN, but yet untested...
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] Fix for IE XML nested each issues (Bug #164)
The current version of jQuery has trouble when trying to access methods such as text() or parent() or attr() inside an each statement within the context of an XML document. For a test case, see
Bug #164. The general assumption with this bug has been that the problem lies in methods such as text(), and therefore it would be impossible to determine whether the object in question was an XML object or a HTML object and act on it accordingly. While this bug has been closed, it is crucial for what I'm using jQuery for, so I decided to debug it and have found a simple yet (as far as I can tell) effective solution to the bug which works in both IE and Firefox, and should work fine in other browsers as well.
The problem itself does not actually lie within the text() method, but instead is caused by this statement within the primary jQuery function body:// Handle HTML stringsvar m = /^[^]*(.+)[^]*$/.exec(a);
As such, any time $(this) is called within the each function body the error is thrown, not just when specific methods such as text() or parent() are called. The error seems to be caused by 'a' being an object instead of a string and IE barfing when trying to execute the regular _expression_ on 'a'.
The fix is quite simple, as far as I can tell... simply replace the line in question with this:// Handle HTML stringsvar m;if (typeof a == string) m = /^[^]*(.+)[^]*$/.exec(a);
Because the regular _expression_ should only be effective when it's executed on a string anyway, this prevents the IE error from being thrown and still preserves the functionality otherwise. In my limited testing so far, I have yet to find any other side effects to this.
Replacing the statement above fixes the text() and parent() functions, however the attr() function still requires some prodding to make it work correctly in an XML context within IE. The troublesome lines within the attr: declaration are (~line 706):
} else if ( elem.getAttribute != undefined ) { if ( value != undefined ) elem.setAttribute( name, value ); return elem.getAttribute( name, 2 );For whatever reason, IE throws an error when checking whether
elem.getAttribute is defined, complaining about an invalid parameter list (despite the fact that it's just a check for existence). When typeof elem.getAttribute is called in IE, the type is reported as unknown, which certainly doesn't help things. IE also doesn't like the function call to
elem.getAttribute with two parameters, so the return statement would have to be changed too. The fix once again is relatively simple. Before the block above, add another similar block that looks like this:} else if (
jQuery.browser.msie elem.getAttribute(name) != undefined ) { if ( value != undefined ) elem.setAttribute( name, value ); return elem.getAttribute( name );This makes attr() work in both IE and Firefox, although I haven't tested in other browsers as of yet.
One last XML related fix I've found within jQuery. When using Xpath expressions, jQuery has a custom _expression_ which allows matching against the content of an element, such as $(p:contains('test')), which will match all p tags which contain text in their body. Once again, IE has trouble with this when processing it in an XML context. The fix is simple, change this line (~line 520):
contains: (a.innerText||a.innerHTML).indexOf(m[3])=0,to this:contains: ((a.firstChild a.firstChild.nodeValue)||a.innerText||a.innerHTML).indexOf(m[3])=0,
And it works as expected in Firefox and IE (and, once again, presumably in other browsers too).I hope these fixes are as much a lifesaver for others as they are for me--most of what I'm doing in jQuery is based on processing XML, and not having the ability to use jQuery functionality within each loops was proving a major pain. I'm not familiar enough yet with SVN or the jQuery checkin process to check these changes into SVN myself--if it's better for me to check them in than for someone more familiar with the process, let me know and I'll work on that tonight.
Any testing in browsers other than IE or Firefox would also be appreciated--the modifications shouldn't really affect any browser other than IE, but I'm not yet familiar enough with _javascript_ to say that with any degree of certainty.
Cheers,~Peter Woods
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Fix for IE XML nested each issues (Bug #164)
Peter Woods schrieb:
The current version of jQuery has trouble when trying to access methods
such as text() or parent() or attr() inside an each statement within the
context of an XML document. For a test case, see Bug #164
http://jquery.com/dev/bugs/bug/164/. The general assumption with this
bug has been that the problem lies in methods such as text(), and
therefore it would be impossible to determine whether the object in
question was an XML object or a HTML object and act on it accordingly.
While this bug has been closed, it is crucial for what I'm using jQuery
for, so I decided to debug it and have found a simple yet (as far as I
can tell) effective solution to the bug which works in both IE and
Firefox, and should work fine in other browsers as well.
The problem itself does not actually lie within the text() method, but
instead is caused by this statement within the primary jQuery function body:
// Handle HTML strings
var m = /^[^]*(.+)[^]*$/.exec(a);
As such, any time $(this) is called within the each function body the
error is thrown, not just when specific methods such as text() or
parent() are called. The error seems to be caused by 'a' being an object
instead of a string and IE barfing when trying to execute the regular
expression on 'a'.
The fix is quite simple, as far as I can tell... simply replace the line
in question with this:
// Handle HTML strings
var m;
if (typeof a == string) m = /^[^]*(.+)[^]*$/.exec(a);
Because the regular expression should only be effective when it's
executed on a string anyway, this prevents the IE error from being
thrown and still preserves the functionality otherwise. In my limited
testing so far, I have yet to find any other side effects to this.
Thank you Peter! I was also quite unhappy to see this bug closed as
wontfix. I was bothered by the same bug.
Looks like it can be fixed finally... :-)
One last XML related fix I've found within jQuery. When using Xpath
expressions, jQuery has a custom expression which allows matching
against the content of an element, such as $(p:contains('test')),
which will match all p tags which contain text in their body. Once
again, IE has trouble with this when processing it in an XML context.
The fix is simple, change this line (~line 520):
contains: (a.innerText||a.innerHTML).indexOf(m[3])=0,
to this:
contains: ((a.firstChild
a.firstChild.nodeValue)||a.innerText||a.innerHTML).indexOf(m[3])=0,
Does this work in Firefox with text nodes that start on a new line?
item
Text node
/item
-- Klaus
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Fix for IE XML nested each issues (Bug #164)
Peter Woods schrieb: Seems to work for me in Firefox for a couple of test cases I made just now to test the new line functionality. I've also done a bit of testing in Safari just now, and the results are similar, namely everything's working fine with the changes applied to the latest SVN. I may work on compiling some formal test cases for this functionality tonight or tomorrow sometime. Would be great if you could post those tests somewhere, so they can be added to the test suite. John already reopended the bug report concerning the first issue... -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
