xpath queries in mozilla are not portable

RESOLVED INVALID

Status

()

RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: dietrich, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
xpath queries in mozilla are not portable: they're not valid against the same document outside of our impl)

possibly because of our dom "fixup"?

doug, can you dupe this, or add more details about what you found in the joey work?
(Reporter)

Updated

12 years ago
Component: General → XML
Product: Firefox → Core
QA Contact: general → xml
thanks for flying this.  I am not sure it is a bug per se, but rather a feature request.

Basically what I am trying to do is:

1) render a page in ff.
2) build an xpath to a given element (A) in ff.
3) send that xpath and url to page to a server.
4) on the server, build a dom document to the url sent.
5) apply the xpath to get the element selected in step 2.


I am using PHP5 on the server.

what I had to do was construct an xpath looking string in firefox instead of using something more standard.

It seams that not all documents are the same, we add a bunch of extra stuff that other parsers dont....  

What I am looking for is a solution -- a canonical xpath.


The code that generates this xpath looking string is here:

http://svn.mozilla.org/labs/joey/trunk/addons/ff/chrome/content/joey/joeyOverlay.js


see joey_buildXPath()

(In reply to comment #1)
> What I am looking for is a solution -- a canonical xpath.

So is this a duplicate of bug 319768?

Updated

12 years ago
Blocks: 374960

Comment 3

11 years ago
I don't think this is a valid bug.  If it is, it's more DOM-related than XML-related.  It's easy to generate a canonical xpath for the fixed-up DOM.  The OP is a complaint that that path doesn't work some other parser's version of the original document.  That's no surprise, because it's a different document.  If you want to use the path with some other parser, you also need to parse the same document.  In this case, it's the in-memory document represented by the DOM.  Canonical paths with that document are portable.

Note: There is one gotcha:  Element.normalize should be called on elements before generating the canonical paths.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.