Intermittent /web-platform/tests/webdriver/tests/[find_elements_from_element | find_elements_from_element]/find.py | test_parent_of_document_node_errors - AssertionError: assert 404 == 400
Categories
(Remote Protocol :: Marionette, defect, P5)
Tracking
(firefox107 disabled)
| Tracking | Status | |
|---|---|---|
| firefox107 | --- | disabled |
People
(Reporter: whimboo, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: intermittent-failure, leave-open, test-disabled)
The test is currently marked as failing.
0:16.94 INFO STDOUT: def assert_error(response, error_code):
0:16.94 INFO STDOUT: """
0:16.94 INFO STDOUT: Verify that the provided webdriver.Response instance described
0:16.94 INFO STDOUT: a valid error response as defined by `dfn-send-an-error` and
0:16.94 INFO STDOUT: the provided error code.
0:16.94 INFO STDOUT:
0:16.94 INFO STDOUT: :param response: ``webdriver.Response`` instance.
0:16.94 INFO STDOUT: :param error_code: String value of the expected error code
0:16.94 INFO STDOUT: """
0:16.94 INFO STDOUT: > assert response.status == errors[error_code]
0:16.94 INFO STDOUT: E assert 404 == 400
0:16.94 INFO STDOUT: E +404
0:16.94 INFO STDOUT: E -400
0:16.94 INFO STDOUT: error_code = 'invalid selector'
0:16.94 INFO STDOUT: response = <Response status=404 error=<StaleElementReferenceException http_status=404>>
0:16.94 INFO STDOUT: testing/web-platform/tests/webdriver/tests/support/asserts.py
0:16.94 INFO STDOUT: :52: AssertionError
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 1•4 years ago
|
||
With the patch from bug 1793920 we do not raise an error anymore but actually return the document when running the following code with the documentElement reference:
find_elements(session, from_element.id, "xpath", "..")
The XPath selector .. is equal to retrieving the parent node and the parent from the documentElement is the document.
James, I'm asking myself why this test should actually raise an "invalid selector" while it's not invalid? Running the following code in the DevTools console works just fine as well:
> document.evaluate("..", document.documentElement, null, 9, null)
< XPathResult { resultType: 9, singleNodeValue: HTMLDocument https://bugzilla.mozilla.org/show_bug.cgi?id=1764594, invalidIteratorState: false }
Might the test be wrong? Or do I miss something?
|
|
Reporter | |
Comment 2•4 years ago
|
||
Hm, the WebDriver classic spec says that we should use ORDERED_NODE_SNAPSHOT_TYPE but we use FIRST_ORDERED_NODE_TYPE. Probably this makes the difference.
|
|
Reporter | |
Comment 3•4 years ago
|
||
While my last comment is true the underlying issue is that we should not return a document as WebElement. That's what my updated patch on bug 1793920 does now. I'll come back here once it is fixed.
|
|
Reporter | |
Comment 4•3 years ago
|
||
As it looks like the definition of finding an element is not complete: https://w3c.github.io/webdriver/#dfn-find
Right now invalid selector is only raised if a DOMException, SyntaxError, XPathException, or other error occurs during the execution of the element location strategy. But this is not the case here given that the XPath selector will get the parent of the documentElement, which is the document. But that's not a valid Element and I think that the find steps need this extra check that the found object is a DOMElement. If not the invalid selector failure needs to be raised.
|
||
Comment 5•3 years ago
|
||
https://w3c.github.io/webdriver/#dfn-xpath-selector step 5.2 seems to cover this?
|
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to James Graham [:jgraham] from comment #5)
https://w3c.github.io/webdriver/#dfn-xpath-selector step 5.2 seems to cover this?
Oh, looks like I missed that. Thanks.
Actually we have bug 1485338 which covers the spec compliance. I'll mark the dependency.
|
||
Comment 7•3 years ago
|
||
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Description
•