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•2 years ago
|
Reporter | ||
Comment 1•2 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•2 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•2 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•2 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•2 years ago
|
||
https://w3c.github.io/webdriver/#dfn-xpath-selector step 5.2 seems to cover this?
Reporter | ||
Comment 6•2 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•2 years ago
|
||
Description
•