Retrieving parent element of HTMLDocument via XPath selector .. fails

RESOLVED FIXED in Firefox 59

Status

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: acdcjunior, Assigned: ato)

Tracking

(Blocks 1 bug)

58 Branch
mozilla59
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox59 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

- geckodriver 0.19.1
- firefox: 57.0.1
I didn't specify the version in the combobox because I didn't find 0.19.1 there.


So, to reproduce the problem, run this code with a FirefoxDriver:

            driver.get("http://www.example.com");
            WebElement htmlTag = driver.findElement(By.cssSelector("html"));
            WebElement htmlParent = htmlTag.findElement(By.xpath(".."));
            System.out.println(htmlParent.getTagName());



Actual results:

Every other driver throws an exception when attempting to get the parent of <html>:

- chrome throws InvalidSelectorException: invalid selector: The result of the xpath expression ".." is: [object HTMLDocument]. It should be an element.
- opera throws InvalidSelectorException: invalid selector: The result of the xpath expression ".." is: [object HTMLDocument]. It should be an element.
- ie throws InvalidSelectorException: The result of the xpath expression ".." is: [object HTMLDocument]. It should be an element.
- edge throws NoSuchElementException: No such element (WARNING: The server did not provide any stacktrace information)
- phantomjs throws InvalidSelectorException: {"errorMessage":"The result of the xpath expression \"..\" is: [object HTMLDocument]. It should be an element." ...}
- htmlunit throws InvalidSelectorException: The xpath expression '..' selected an object of type 'class com.gargoylesoftware.htmlunit.html.HtmlPage' instead of a WebElement

But geckodriver only throws when we attempt to interact with the obtained html WebElement (not at the .findElement() point, like the others).

Geckodriver then throws:
- StaleElementReferenceException: The element reference of [object HTMLDocument] {...} stale; either the element is no longer attached to the DOM, it is not in the current frame context, or the document has been refreshed


Expected results:

You guys may leave at it is, or may make geckodriver return an error like all others. Your decision, of course. I just thought you should know.
There is a change with bug 1400256 which will be shipped with Firefox 58. With the changes included the element will no longer be added, because of an unknown type.

1513170369433	Marionette	TRACE	3 -> [0,15,"findElement",{"using":"xpath","value":"..","element":"d104e736-2dff-e64b-8524-346d6cfd7cbf"}]
1513170369441	Marionette	TRACE	3 <- [1,15,{"error":"unknown error","message":"TypeError: Expected an element or WindowProxy, got: [object HTMLDocument] {\"location\":{\"href\":\"http://www.example.com/\",\"orig ... om\",\"protocol\":\"http:\",\"host\":\"www.example.com\",\"hostname\":\"www.example.com\",\"port\":\"\",\"pathname\":\"/\",\"search\":\"\",\"hash\":\"\"}}","stacktrace":"add@chrome://marionette/content/element.js:150:13\nfindElementContent@chrome://marionette/content/listener.js:1257:10\n"},null]

It's not the failure we would expect, right. So we should be better.

Andreas, could you have a look why we do not throw an invalid selector exception? Maybe Firefox itself accepts it and doesn't throw?
Flags: needinfo?(ato)
Status: UNCONFIRMED → NEW
Component: geckodriver → Marionette
Ever confirmed: true
Assignee

Comment 2

2 years ago
It looks like element.isDOMElement does not recognise HTMLDocument
as a “DOM element” because it does not have a nodeType.
Assignee: nobody → ato
Blocks: webdriver
Status: NEW → ASSIGNED
Flags: needinfo?(ato)
OS: Unspecified → All
Hardware: Unspecified → All
Summary: geckodriver allows to "find" parent of <html> and then throws a StaleElementReferenceException upon interaction → HTMLDocument not recognised in element.isDOMElement
Version: unspecified → 58 Branch
Andreas, with your last modification of the bug the original reported problem is not covered anymore. Fixing the element store `add` method should be a different bug.
Flags: needinfo?(ato)
Assignee

Comment 4

2 years ago
(In reply to Henrik Skupin (:whimboo) [mostly away Dec 11th - Jan
3rd] from comment #3)

> Andreas, with your last modification of the bug the original
> reported problem is not covered anymore. Fixing the element store
> `add` method should be a different bug.

What?  We need to introduce a new function, probably
element.isHTMLDocument or some such, which gets called in
element.Store#add.
Flags: needinfo?(ato)
Assignee

Comment 5

2 years ago
Sorry, I may have misunderstood the core issue here.  The issue
isn’t, like I indicated, that an HTMLDocument fails to be recognised
by element.isDOMElement (it is), but that an XPath selector looking
up the parent of the document element either fails to reject the
selector (because it is invalid) or because the element it fetches
isn’t a valid HTMLDocument (somehow).
Summary: HTMLDocument not recognised in element.isDOMElement → Retrieving parent element of HTMLDocument via XPath selector .. fails
Assignee

Comment 6

2 years ago
So the question is if the XPath selector is invalid, in which case
we should return an invalid selector error, or if there is something
wrong with the element reference it does locate, because normally
HTMLDocument should pass all the requirements in element.isDOMElement.
Assignee

Comment 7

2 years ago
Some further investigation shows that
document.documentElement.nodeType is 1 (Node.ELEMENT_NODE) but
that the element returned by the XPath query has a nodeType of 9
(Node.DOCUMENT_NODE).

This means the selector does not return an error in Firefox and
that if we want to consider the selector valid we need to add
DOCUMENT_NODE to element.isDOMElement.
Assignee

Updated

2 years ago
Depends on: 1400256
Assignee

Comment 8

2 years ago
Taking a closer look at the errors you are seeing in the other seeing:

> - chrome throws InvalidSelectorException: invalid selector: The result of the xpath expression ".." is: [object HTMLDocument]. It should be an element.

This means Chrome has the same bug as we do, in fact.  They look
at the result of the XPath evaluation and inspect the element’s
nodeType.  It doesn’t match 1 so they error.  We fail for a slightly
different reason, but I draw the conclusion from this that all the
browsers should support finding an element from <html> using the
".." XPath expression.
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 12

2 years ago
mozreview-review
Comment on attachment 8936885 [details]
Bug 1424635 - Consider DOCUMENT_NODE a valid web element.

https://reviewboard.mozilla.org/r/207612/#review213506

::: commit-message-fb519:8
(Diff revision 1)
> +When looking up the parent of <html> using an XPath parent expression
> +such as "..", the nodeType of the returned HTMLDocument will be 9
> +(DOCUMENT_NODE).  <html> is a valid web element and we should be
> +able to serialise and return it to the user.
> +
> +It is worth noting that other WebDriver implemenations fail this

s/implemenations/implementations
Attachment #8936885 - Flags: review?(dburns) → review+

Comment 13

2 years ago
mozreview-review
Comment on attachment 8936884 [details]
Bug 1424635 - Test element retrieval of HTMLDocument.

https://reviewboard.mozilla.org/r/207610/#review213510

This commit should either be combined with the previous commit or the tests from previous commit should be combined here.
Comment hidden (mozreview-request)
Assignee

Updated

2 years ago
Attachment #8936884 - Attachment is obsolete: true
Attachment #8936884 - Flags: review?(dburns)
Comment hidden (mozreview-request)

Comment 16

2 years ago
Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3870805aea81
Consider DOCUMENT_NODE a valid web element. r=automatedtester

Comment 17

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3870805aea81
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.