Patches for cloneNode bug in HTMLSelectElementImpl, HTMLTableElementImpl, HTMLFormElementImpl, HTMLMapElementImpl, HTMLTableElementImpl, HTMLTableRowElementImpl, and HTMLTableSectionElementImpl

[Aaron Kardell <ak...@altonaed.com>]

I believe a problem affects all of the following methods if they occur after a
call to cloneNode():

HTMLSelectElementImpl.getOptions()
HTMLTableElementImpl.getRows()
HTMLFormElementImpl.getElements()
HTMLMapElementImpl.getAreas()
HTMLTableElementImpl.getTBodies()
HTMLTableRowElementImpl.getCells()
HTMLTableSectionElementImpl.getRows()

They all appear to return the wrong cached results, if the following sequence of
events occurs (HTMLSelectElementImpl is used as an example):

1) You have a variable, origSelect, to an HTMLSelectElementImpl object
2) You call origSelect.getOptions()
3) You call origSelect.cloneNode(true) and assign it to the variable clonedSelect
4) Your call to clonedSelect.getOptions() inappropriately returns the same
result as a call to origSelect.getOptions()

I have posted the results of my findings to an existing issue in Jira:
XERCESJ-525 <http://nagoya.apache.org/jira/browse/XERCESJ-525>

I have attached patch files that I believe fix the problem by clearing the
cached items upon a cloned node, and I will also include a file called
TestingSelectCloneNode.java which reproduces this behavior with a similar test
case to that provided above.  The test case fails with current CVS versions of
Xerces, but is successful with the patches I've provided.

This appears to not be platform, OS, or JDK specific.

I hope I have attached these in the appropriate way.  Please let me know when
they might be integrated into CVS, or if there are other steps I need to take to
make sure these get into CVS.  I grant any and all permission needed under the
Apache license to reuse these patch files and their resulting changes to source
code files, as well as the test case.

Regards,

Aaron
---
Aaron Kardell
Development Manager & Chief Architect of SiPS
Altona Ed, LLC <http://www.altonaed.com/>

Re: Patches for cloneNode bug in HTMLSelectElementImpl, HTMLTableElementImpl, HTMLFormElementImpl, HTMLMapElementImpl, HTMLTableElementImpl, HTMLTableRowElementImpl, and HTMLTableSectionElementImpl

[Michael Glavassevich <mr...@ca.ibm.com>]

Hi Aaron,

Thanks for submitting patches for this problem and also for providing a 
test case which made it much easier to assess your patches. I've committed 
them to CVS.

Aaron Kardell <ak...@altonaed.com> wrote on 05/26/2004 06:33:56 PM:

> I believe a problem affects all of the following methods if they occur 
after a
> call to cloneNode():
> 
> HTMLSelectElementImpl.getOptions()
> HTMLTableElementImpl.getRows()
> HTMLFormElementImpl.getElements()
> HTMLMapElementImpl.getAreas()
> HTMLTableElementImpl.getTBodies()
> HTMLTableRowElementImpl.getCells()
> HTMLTableSectionElementImpl.getRows()
> 
> They all appear to return the wrong cached results, if the following
> sequence of
> events occurs (HTMLSelectElementImpl is used as an example):
> 
> 1) You have a variable, origSelect, to an HTMLSelectElementImpl object
> 2) You call origSelect.getOptions()
> 3) You call origSelect.cloneNode(true) and assign it to the variable
> clonedSelect
> 4) Your call to clonedSelect.getOptions() inappropriately returns the 
same
> result as a call to origSelect.getOptions()
> 
> I have posted the results of my findings to an existing issue in Jira:
> XERCESJ-525 <http://nagoya.apache.org/jira/browse/XERCESJ-525>
> 
> I have attached patch files that I believe fix the problem by clearing 
the
> cached items upon a cloned node, and I will also include a file called
> TestingSelectCloneNode.java which reproduces this behavior with a 
similar test
> case to that provided above.  The test case fails with current CVS 
versions of
> Xerces, but is successful with the patches I've provided.
> 
> This appears to not be platform, OS, or JDK specific.
> 
> I hope I have attached these in the appropriate way.  Please let me know 
when
> they might be integrated into CVS, or if there are other steps I 
> need to take to
> make sure these get into CVS.  I grant any and all permission 
neededunder the
> Apache license to reuse these patch files and their resulting 
> changes to source
> code files, as well as the test case.
> 
> Regards,
> 
> Aaron
> ---
> Aaron Kardell
> Development Manager & Chief Architect of SiPS
> Altona Ed, LLC <http://www.altonaed.com/>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org