Closed Bug 1424635 Opened 7 years ago Closed 6 years ago

Retrieving parent element of HTMLDocument via XPath selector .. fails

Categories

(Remote Protocol :: Marionette, defect)

Product:
Remote Protocol
Component:
Marionette
Version:
58 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox59 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla59
Tracking Flags:
Tracking Status
firefox59 --- fixed

People

(Reporter: acdcjunior, Assigned: ato)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Bug 1424635 - Consider DOCUMENT_NODE a valid web element.
59 bytes, text/x-review-board-request
automatedtester
: review+
Details 
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
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)
(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)
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
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.
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.
Depends on: 1400256
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 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 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.
Attachment #8936884 - Attachment is obsolete: true
Attachment #8936884 - Flags: review?(dburns)
Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3870805aea81
Consider DOCUMENT_NODE a valid web element. r=automatedtester
https://hg.mozilla.org/mozilla-central/rev/3870805aea81
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: