in reply to Re^2: Some issues with WWW::Mechanize::Firefox->xpath() method
in thread Some issues with WWW::Mechanize::Firefox->xpath() method

The JS glue just passes along whatever document.evaluate returns, after converting that array-like XPathResults list into a plain array:

function(doc,q,ref,cont) { var xres = doc.evaluate(q,ref,null,XPathResult.ORDERED_NODE_SN +APSHOT_TYPE, null ); var map; if( cont ) { map = cont; } else { // Default is identity map = function(e){ return e }; }; var res = []; for ( var i=0 ; i < xres.snapshotLength; i++ ) { res.push( map(xres.snapshotItem(i))); }; return res }

I'm no expert on XPath and its semantics, but if somebody submits a bug report and preferrably a self-contained example, I can investigate things closer.

Replies are listed 'Best First'.
Re^4: Some issues with WWW::Mechanize::Firefox->xpath() method
by dfaure (Chaplain) on Apr 02, 2013 at 13:10 UTC
    I'm no expert on XPath and its semantics, but if somebody submits a bug report and preferrably a self-contained example, I can investigate things closer.

    You may safely use the code I provided in the OP as example. I'm simply using Firebug+FirePath addons on the target Firefox, to get results from javascript only.

    According to https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMXPathResult#Type_constants, I think the problem comes from the parameters given to the XPath evaluator, which limits the retrieved elements to nodesets. IMHO, the solution would be to use XPathResult.ANY_TYPE and perhaps a more elaborated function than identity to build the result set.

    Should I open a bug on RT for this?

    ____
    HTH, Dominique
    My two favorites:
    If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
    Bien faire, et le faire savoir...