After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 158766 - choose/when changes the actual node
choose/when changes the actual node
Status: VERIFIED DUPLICATE of bug 151201
Product: libxslt
Classification: Platform
Component: general
1.1.8
Other Linux
: High major
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2004-11-20 00:35 UTC by Vojtech Hala
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vojtech Hala 2004-11-20 00:35:05 UTC
To reproduce the bug, unpack the following file and run make.
http://hyperkrychle.cz/etc/libxsltbug.tar.gz
The result is in example.txt.

The template "ctor-args" is called 3 times exactly the same way, but for the
first time it gives different (incorrect) result. This is because of a weird
behavior of the choose/when part of the "class-lookup" template. Note that the
strange behavior disappears if you replace the 'choose/when' by a single 'if'
statement, which should be exactly equivalent.

I have discovered that the 'href' attribute is (for the first call) not
accesible from inside the 'when' element, but there is an attribute 'name'. Try
to uncomment the second 'value-of'. This shows that libxslt changes the actual
node after evaluating the condition. It is somehow switched to the node found in
the test.

And furthermore I found out that it has something to do with keys. If you remove
the <key/> element from the stylesheet, it behaves correctly. And if you change
the match attribute of the key, it behaves badly but the @name is suddenly not
accessible from the <when/> element. The <key/> definition affect the strange
context switching, although it's never used.

MSxml and 4xslt behave well at this point.
Comment 1 Daniel Veillard 2004-11-20 10:53:08 UTC
Can you check first that you can reproduce it first with the last versions
libxslt-1.1.12, and libxml2-2.6.16 as asked in the bug report page.

Daniel
Comment 2 Vojtech Hala 2004-11-20 15:05:46 UTC
Alright. Now I've checked it in libxslt-1.1.11 and libxml2-2.6.15 which are in
slackware-current. The problem is not appearing in these versions, so it has
probably been solved. I'm sorry. I have observed it on newest versions available
in Debian - libxslt-1.1.8 and libxml2-2.6.11.
Comment 3 William M. Brack 2004-11-24 03:02:10 UTC

*** This bug has been marked as a duplicate of 151201 ***
Comment 4 Daniel Veillard 2005-09-05 09:44:15 UTC
This should be closed by release of libxslt-1.1.15

  thanks,

Daniel