4031651 / ajaxslt Goto Github PK

As implemented, in an HTML xpath like "//div", xpath.js attempts to
recursively collect all descendants before running the node test.  This
performs slowly because it will first attempt to iterate through every
child node in the document, and only then filter out those that are not divs.

Applying the nodetest earlier would help, but it's even better to run the
universal JS function written in C to do precisely this: getElementsByTagName.

I've attached a patch that will handle this case.  Instead of blindly
recursively collecting descendants, we attempt to extract a tag name from
the node test if possible.  (If the node test is NodeTestName, use the
name; if it's NodeTestAny or NodeTestElementOrAttribute, use "*".)  Then we
skip the node test loop at the end of StepExpr, in order to avoid
needlessly cloning the context.

To make this work, I had to do a bit of fancy footwork in the parser as
well.  As currently implemented, gathering descendants happens in one step,
and then running the node test happens in a following step (on the child
axis).  I modified makeLocationExpr2, makeLocationExpr7 and makePathExpr2
to unify cases like these into a single step that applies the nodetest on
the descendant-or-self axis.

This patch is more ambitious than some of the others, so I'm not checking
it in right away...  I'd like someone to code review it before I apply it.
 On my machine it results in a big performance increase; 70% in some cases.

What steps will reproduce the problem?
1. use the sample code that comes with ajaxslt with one modification on the
xml that follows:
<page>
<message><![CDATA[
<b>Hello</b> World.
]]></message>
</page>

2. Run it through AJAXSLT

What is the expected output? What do you see instead?
The expected output should be this:
<div style="color:green">
<b>Hello</b> World.
</div>

However the acutal output is this:
<div style="color:green">
&lt;b&gt;Hello</b> World.
</div>

What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.

Please provide any additional information below.
Maybe I am not doing it correctly. If I am not please point out what I am
doing wrong.

What steps will reproduce the problem?
1. trying to transfrom this xml:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="AA">
Hello World!
</page>

2. using this xslt:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:aa="AB">

<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>

<xsl:template match="aa:page">
   <xsl:value-of select="."/>
</xsl:template>

</xsl:stylesheet>

I expect to see:
Hellow world!

But result is empty.


What version of the product are you using? On what operating system?
MsWindows XP SP 2
Opera 9.26
FF 2.0.0.12
ajaxslt-0.8.1.tar.gz

Please provide any additional information below.

Another view on the same bug:
lets transform following xml:
<?xml version="1.0" encoding="UTF-8"?>
<aa:page xmlns:aa="AA">  <!-- AA namespace -->
Hello World!
</aa:page>

with following xslt:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:aa="ZZ"> <!-- ZZ namespace -->

<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>

<xsl:template match="aa:page">
   <xsl:value-of select="."/>
</xsl:template>

</xsl:stylesheet>

Expected result: Empty, because namespaceses actually are different.
Actual result: Hello World!


It looks like engine doesn't handle namespace prefixes at all, treating
them just as begining of tags names.

What steps will reproduce the problem?
1. Create an XML fragment with an Axis specifier as a node name e.g.
parent, child etc...
2. Create an XSL template with an Xpath Query which selects based on node
name. e.g. <xsl:value-of select="//child"/>
3. The Xpath doesn't output any results and the js method reports no
exception or handled exceptions.

Attached is the source with a HTML page in the test folder. This should
help recreate the fault.

What is the expected output? What do you see instead?
I would expect to see the XSLT to output the result of the xsl:value-of
select when using 'child' in the expression.


What version of the product are you using? On what operating system?
ajaxslt0.8.1, Windows XP SP2, Mozilla Firefox 3.5.5

Please provide any additional information below.
I think the problem is 'child' and 'parent' are considered delimited node
names within an xpath. However they only become delimited when the '::'
double colon is used. Otherwise they should be considred a qualified name
(QName) rather tthan an Axis specifier. 

Run the xmltoken_unittest.html on Safari.  testXmlName11 will fail on #27.

(I don't really understand what this test is attempting to cover... what is
being verified here?)

Tested on Safari 3.0.4 Beta on Windows, Safari 3 for OS X 10.4 (Tiger) and
Safari 2 for OS X 10.4.

What steps will reproduce the problem?
See the file attached and open it with Firefox and IE. Click on "TestMe!".

What is the expected output? What do you see instead?
You should see "Result: 1" twice. That means that the XPath requests are
correctly executed. With IE the first request works but not the other one,
consequently you should see "Result: 1" and then "Result: 0"

What version of the product are you using? On what operating system?
v0.8.1

https://sourceforge.net/tracker/index.php?func=detail&aid=1459468&group_id=14099
9&atid=748118

I hit some of the "not implemented yet" items and a few others I spotted
before deciding that this probably doesn't suit my purposes. Still, the
changes I've made may prove useful to you (or not), so here they are.

TODO Items done:
    local-name
    namespace-uri
    xsl:message

Bug in translate function.
To reproduce:
1. run stylesheet that will do translate('abc','aba','xaz')

Expected output is string 'xac' as spec says "If a character occurs more
than once in the second argument string, then the first occurrence
determines the replacement character". Instead output is "xzc" (string gets
changed first to "xbc" then "xac" and then "xzc").

XPath extensions for XSLT that were are not supported:
    current
    document (support added is not complete - also could fail on some
platforms, but will report this through a call to function-available properly.)
    element-available
    function-available
    generate-id
    system-property
Still not supported, but now report their not-implemented status:
    format-number
    key

Calls to empty function xpathLog do nothing. Replace with commented out;
someone implementing xpathLog can also do a find and replace to turn
"//xpathLog" to "xpathLog".

Although the release notes of ajaxslt-0.4 states that 'xsl:sort' is fixed
in 'xsl:for-each' iterations, it seems to me that this still isn't fixed
completely. I have seen that a bug related to this issue was already
entered in the sf.net bugtracker, bug 1520401 - Sort is invalid, though
this bug report doesn't describe the issue properly but contains just a
post of xslt and xml instead.

I've looked at the ajaxslt source and located the issue. I found that
method "xsltProcessContext" calls the xsltSort on a sortContext without all
childnodes in its nodelist. Then method "xsltForEach" is called to do the
actual "xsl:for-each". It reads the nodelist from the context and uses it
without sorting it.

This issue can be fixed by retrieving the nodelist, then sorting it and
calling xsltForEach with the sorted context. The nodelist is always
retrieved from the "select" attribute within the "xsl:for-each" element, as
the select attribute is required with for-each iterations, while optional
for apply-templates.

A patch against xslt.js of release 0.4 is attached.

What steps will reproduce the problem?
     <a>
       <xsl:attribute name="href">
         test.php?test
       </xsl:attribute>
       <xsl:attribute name="target">mainframe</xsl:attribute>
       test
     </a>


What is the expected output? What do you see instead?
<a href="test.php?test" target="mainframe">test</a>

What version of the product are you using? On what operating system?
8.1

Please provide any additional information below.

strip-space is not implemented

https://sourceforge.net/tracker/index.php?func=detail&aid=1508596&group_id=14099
9&atid=748118

What steps will reproduce the problem?
1. Use an xpath expression that has a variable containing a node list.
2. Reference a child of this node list using the absolute '/' operator
3. JS exception is thrown about how the expression can't be parsed.

What is the expected output? What do you see instead?

Expect to see the string $var/foo parsed. Instead a js exception is thrown.


What version of the product are you using? On what operating system?

Tried using the latest from trunk (ajaxslt v7) still an issue. OS X 10.4


Please provide any additional information below.

Stepping through the source with a js debugger the issue is resolving
precedence with the '/' operator. In the xpathTokenRules object, '//' has a
prec of 19 and '/' of 30. Inside of xpathReduce() when calculating the prec
of the candidate and ahead, will fail to pop the stack. It is comparing the
prec of XPathFilterExpr which is set to 20 and '/' which is 30.

Modifying line 1927: 

[ XPathFilterExpr, [ XPathPrimaryExpr, XPathPredicate, Q_MM ], 31,
makeFilterExpr ],

to use a prec value of 31 instead of 20 solved the issue for me and allowed
the expression to be parsed. However I am not sure of all the consequences
of changing this prec value.

What steps will reproduce the problem?
1. Create a xsl that uses the document function to include some external
xml (see attached files)

What is the expected output? 
Standard:
Working :)
Document function:
Working :) 
What do you see instead?
I get an uncaught exception in firefox that I haven't been able to locate
the source of.

What version of the product are you using? On what operating system?
ajaxslt-0.8.1

Please provide any additional information below.

What steps will reproduce the problem?
xsltProcess() cannot transform the attached xml file with the xsl file
attached. Both these file works in Stylus and firefox.
The <xsl:value of select="tagname[@id='id']/@name" /> statements cannot be
executed successfully.

What is the expected output? What do you see instead?
Try to reproduce with the attachment.

What version of the product are you using? On what operating system?
AJAXSLT 0.7
Firefox under Windows XP SP2.

Please provide any additional information below.

Change the 'xsltProcess' function to the following to support passing a 
hash of parameters as third parameter to this function:

function xsltProcess(xmlDoc, stylesheet, params) {
  var output = domCreateDocumentFragment(new XDocument);
  var c = new ExprContext(xmlDoc);
  if(params) {
    for(var p in params)
      c.setVariable(p, new StringValue(params[p]));
  }
  xsltProcessContext(c, stylesheet, output, params);
  var ret = xmlText(output);
  return ret;
}

http://www.llamalab.com/js/xpath/benchmark.html lists a number of JS tests.
 We're doing quite well on performance, but we disagree with FF's native
XPather on a number of tests

descendant::node()
  native returns 248 nodes
  ajaxslt returns 88 nodes
//LI[1]
  native returns 2 nodes
  ajaxslt returns 1 node
//LI[last()]/text()
  native returns 2 nodes
  ajaxslt returns 1 node
//LI[position() mod 2]/@class
  native returns 2 nodes
  ajaxslt returns 1 node

Not sure about that first one, but there's a pretty clear explanation for
all those "//LI" tests.  Haw-bin wrote:

----
I'm a little torn on this. It looks like one of the optimizations [Dan]
made back when we released AJAXSLT 0.8 is contrary to the XPath spec.
Specifically, in xpath.js LocationExpr.prototype._combineSteps , the
sequence of DESCENDANT_OR_SELF and CHILD is combined into DESCENDANT.
Unfortunately, the spec states explicitly that these are not equal:

NOTE: The location path //para[1] does not mean the same as the location
path /descendant::para[1]. The latter selects the first descendant para
element; the former selects all descendant para elements that are the first
para children of their parents.

This has us not passing muster on some of the llamalab benchmarks: 
http://www.llamalab.com/js/xpath/benchmark.html [www.llamalab.com]

What I'm torn about is ... that removing the combining code re-introduces a
pretty big performance hit, at least for the special browser we all know
and love. On the other hand, these inconsistencies mean that relatively
simple XPaths that work in other browsers with native engines potentially
won't work in IE.
----

It took me a while to get my head around this... basically, [1] modifies
the context within the slash, but since //LI[1] is really
/descendant-or-self::node()/LI[1], it only modifies the part after the
second slash.

http://sourceforge.net/tracker/index.php?func=detail&aid=1375469&group_id=140999
&atid=748120

https://sourceforge.net/tracker/index.php?func=detail&aid=1345368&group_id=14099
9&atid=748118

n its simplest form, "<xsl:apply-templates />" with no
arguments does not work as expected. From the w3c: "In
the absence of a select attribute, the
xsl:apply-templates instruction processes all of the
children of the current node, including text nodes."
Currently the "select" attribute must be specified.

What steps will reproduce the problem?

1. XML document

<page>
<message>
Hello World.
</message>
</page>

2. XSL transformation

<xsl:stylesheet>
<xsl:template match="/page">
<xsl:apply-templates select="message"/>
</xsl:template>
<xsl:template match="message">
<div style="color:green">
<xsl:value-of select="."/>
</div>
</xsl:template>
</xsl:stylesheet>

What is the expected output? What do you see instead?
I expected the output to be equivalent to the test example, that is:

<div style="color:green">
Hello World.
</div>

However, the actual output is empty.

What version of the product are you using? On what operating system?
ajaxslt-0.7 and ajaxslt svn
Microsoft Windows XP SP2
Firefox 2.0.0.1
Microsoft Internet Explorer 6

Please provide any additional information below.

<xsl:template match="*|/">
  <xsl:apply-templates/>
</xsl:template>

( see http://www.w3.org/TR/xslt#built-in-rule )

Adding this equivalent of the built-in template rule that should apply to
allow recursive processing to continue in the absence of a successful
pattern match by an explicit template rule in the stylesheet produces :

<div style="color:green">
Hello World.
</div>
<div style="color:green">
Hello World.
</div>

I attached builtin.xml that refers to builtin.xsl. Opening builtin.xml in
firefox or internet explorer produces the expected result.

Thank you.
G.

http://sourceforge.net/tracker/index.php?func=detail&aid=1583867&group_id=140999
&atid=748120

What steps will reproduce the problem?
1. Run this code:
<xsl:stylesheet>
  <xsl:template match="/">
    <xsl:variable name="header">
      <tr>
        <th>Element</th>
        <th>Description</th>
      </tr>
    </xsl:variable>

    <xsl:apply-templates select="page/message"/>
  </xsl:template>

  <xsl:template match="page/message">
    <div>
      <xsl:value-of select="."/>
    </div>
  </xsl:template>
</xsl:stylesheet>

using this XML:
<page>
<message>
Hello World.
</message>
</page>


What is the expected output? What do you see instead?
I expect that a local variable will be created in the root template. That
can be used later. The final output should be:
<div>
Hello World.
</div>

What I actually get is an error that crashes the javascript. When I view
the javascript console in FireFox this is what the error comes up as:
Error: input.node.ownerDocument has no properties
Source File: xslt.js
Line: 356

What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.

What steps will reproduce the problem?
1. Have the following HTML file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
   <script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/xmltoken.js"></script>
   <script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/util.js"></script>
   <script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/dom.js"></script>
   <script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/xpath.js"></script>
   <script>
       function tryMe() {
           var expr = xpathParse("/html/body/h1");
           var result = expr.evaluate(new ExprContext(document));
           var s = result.nodeSetValue();
           alert(s.length);
       }
       window.onload = tryMe;
   </script>
</head>
<body>
   <h1>Test</h1>
</body>
</html>

2. Open this file in your browser

What is the expected output? What do you see instead?

The expected output is '1', but 0 results are found using this XPath ("//h1" 
works just fine).

What version of the product are you using? On what operating system?

I'm using version 0.8.1.

template like:

<xsl:template name="emptyOption">
  <option value="">no value</option>
</xsl:template>

producies the floowing result:

<option>no value</option> instead of <option value="">no option</option>

What steps will reproduce the problem?
See the file attached and test it on

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1.  Evaluate an expression of the form: ../principal * instance('rate')
('instance' is an XPath function specific to XForms but any function call 
will exhibit the same behavior). The inverse, FunctionCall * LocationPath, 
will fail as well.

What is the expected output? What do you see instead?
The expected output is the value of the node selected by the location expr 
multiplied by the result of the function call expr. The actual result is 
an xpath parse error because the stack contains two Expr objects.


What version of the product are you using? On what operating system?
ajaxslt-0.8.1, Windows XP.

Please provide any additional information below.
The Ubiquity XForms project is using ajaxslt and this issue was discovered 
using one of our sample forms. The relative location path is fully reduced 
to an Expr but there is no rule for an Expr followed by TOK_ASTERISK and 
the asterisk is lost. The following function call is also fully reduced to 
an Expr but now you have two Expr objects left on the stack.

Adding the rule: [ XPathExpr, [ XPathExpr, TOK_ASTERISK], 0, passExpr, 
ASSOC_LEFT ] to xpathGrammarRules solved the problem for us. A patch with 
that one simple change is attached.

Selenium bugs SEL-444 and SEL-486 can be reproduced using the following
xpaths: 
id('nested1')/div[1]//input[2]
id('foo')//div[contains(@id, 'useful')]//input

More detail is available in Selenium JIRA.

http://jira.openqa.org/browse/SEL-444
http://jira.openqa.org/browse/SEL-486

http://sourceforge.net/tracker/index.php?func=detail&aid=1596549&group_id=140999
&atid=748120

What steps will reproduce the problem?
1. Test the xmlEscapeText function with this string: Im <b>bold</b>!

What is the expected output? What do you see instead?
I expect it to produce: Im &lt;b&gt;bold&lt;/b&gt;!
However this is what is produced: Im &lt;b&gt;bold</b>!

What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.

Please provide any additional information below.
I believe that the function needs to be modifed from this:
function xmlEscapeText(s) {
  return ('' + s).replace(/&/, '&amp;').replace(/</, '&lt;').
    replace(/>/, '&gt;');
}

To this:
function xmlEscapeText(s) {
  return ('' + s).replace(/&/g, '&amp;').replace(/</g, '&lt;').
    replace(/>/g, '&gt;');
}

That way all the < & and > are found in the string.

I dont know if this is the behavior that you are wanting.

What steps will reproduce the problem?
1. Download the ajaxslt package.
2. Run the xpath.html file in IE6/7, safari, and firefox.
3. Get the error on load.

What is the expected output? What do you see instead?
I would expect to see a successful parsing of the files, instead I am 
shown a Error when I click on parse.

Error "this.nodetest.parsetree is not a function" is the result I get on 
Firefox on linux.  IE6 on winxp I get "xpath parse error: stack exception 
xpath parse error".  Safari 2.0.4 on OSX 10.4 PPC I get "EXCEPTION 
TypeError - Undefined Value" 

What version of the product are you using? On what operating system?
See message above.

Please provide any additional information below.

What steps will reproduce the problem?
1. Create an HTML document that uses a link like this: <a
href="javascript:doFoo('a', 'b')">javascript href with spaces</a>
2. Attempt to match this expression with the xpath
//a[@href="javascript:doFoo('a', 'b')"]

What is the expected output? What do you see instead?
On FF2 & IE7, the expression matches.  On IE6, the expression fails.

This is because on IE6, the browser returns the attribute value as
javascript:doFoo('a',%20'b'), for reasons that man may never understand.

This was SEL-347; it was fixed in a hack that worked around AJAXSLT that
didn't work for more complex XPath expressions.  We should fix it in "real"
AJAXSLT as well and then get rid of the hack in Selenium.
http://jira.openqa.org/browse/SEL-347

What steps will reproduce the problem?
1. Produce two XDocument instances
2. Clone (make a copy of) a node from one document
3. Invoke appendChild, replaceChild or insertBefore to place the clone in 
the second document.

What is the expected output? 

When the cloned node is placed in the new document, its ownerDocument 
should be the new document.

What do you see instead?

The ownerDocument is still the old document.

What version of the product are you using? 

Up to at least r61

On what operating system?

All.

Please provide any additional information below.

Some XPath evaluations, e.g. absolute ones, request the ownerDocument of a 
node, at which point you end up in the wrong document.

Found when fixing
https://sourceforge.net/tracker/index.php?func=detail&aid=1459468&group_id=14099
9&atid=748118

The XPath spec says that a node-set is "an unordered collection of nodes
without duplicates". In certain situations, we're not removing duplicates
in the node-sets. If I'm not mistaken, the following two expressions should
return identical node-sets:

  /descendant-or-self::*/A

  /descendant::A/../A

However, the second expression returns duplicates in its node-set (example
page:
http://code.google.com/p/jsprofile/source/browse/trunk/test/functional/ajaxslt/n
ews.google.com.html)

We can take a look at how other engines (i.e. cybozu) detect duplicates;
comparing nodes using "===" is non-performant.