Improve wdspec tests for "no such element" and "stale element reference" for Switch to (Parent) frame
Categories
(Testing :: geckodriver, task, P3)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
References
Details
As noticed on bug 1684827 comment 37 we miss some tests for no such element
and stale element reference
for the commands Switch To Frame
and Switch To Parent Frame
. Except for Firefox other browsers are failing to correctly throw no such element
when trying to access an element from a different frame (browsing context).
Reporter | ||
Comment 1•4 years ago
|
||
So in the WebDriver spec the no such element error is described as:
An element could not be located on the page using the given search parameters.
So I wonder if trying to access elements that were previously retrieved from a different browsing context should really throw this error. If yes, we would have to update the WebDriver spec to make the message clearer by maybe including the different browsing context
.
James, your feedback here would be welcome.
Comment 2•4 years ago
|
||
So the normative spec text here (starting from e.g. find element from element) is :
Let start node be the result of trying to get a known connected element with url variable element id.
"get a known connected element" is defined as:
- Let element be the result of trying to get a known element with argument reference.
- If element is not connected return error with error code stale element reference.
- Return success with element.
"get a known element" is defined as:
- Let element be the item in the current browsing context’s list of known elements for which the web element reference is equal to reference, if such an element exists. Otherwise return error with error code no such element.
- If element is stale, return error with error code stale element reference.
- Return success with element.
And "stale" is defined as:
An element is stale if its node document is not the active document or if its context object is not connected.
So elements from a different browsing context will always return "no such element" since they're never in the current browsing context's list of known elements. Elements that were previously found in the same browsing context but are either in a document that's no longer active, or that have been removed from the document, will return "stale element reference".
The part of the spec that's "wrong" here is that it assumes the top-level browsing context in a given tab is an invariant, whereas post site isolation that isn't the case any more. I think we should a) assume that there's a 1:1 association between tabs and "browsing contexts" here, even though the Window object will change when we have a cross-site navigation and b) discourage clients from paying too much attention to the difference between "stale element error" and "no such element"; I think it was a mistake to have multiple error codes here.
Reporter | ||
Comment 3•4 years ago
|
||
(In reply to James Graham [:jgraham] from comment #2)
So elements from a different browsing context will always return "no such element" since they're never in the current browsing context's list of known elements. Elements that were previously found in the same browsing context but are either in a document that's no longer active, or that have been removed from the document, will return "stale element reference".
Ok, so my confusion was really only around the informative
text for the no such element
error. Thanks.
The part of the spec that's "wrong" here is that it assumes the top-level browsing context in a given tab is an invariant, whereas post site isolation that isn't the case any more. I think we should a) assume that there's a 1:1 association between tabs and "browsing contexts" here, even though the Window object will change when we have a cross-site navigation and b) discourage clients from paying too much attention to the difference between "stale element error" and "no such element"; I think it was a mistake to have multiple error codes here.
Would you be able to help here in terms of filing the webdriver spec issue and getting the content updated? I'm happy to add all the relevant webdriver tests according to these changes.
Comment 4•4 years ago
|
||
I think we want to revisit this after JakeA completes his changes to the session hsitory/navigation model in the HTML spec. That is going to introduce the concept of a "top-level navigable" which is what WebDriver calls a "window" and the spec inaccurately conflates with a "top-level browsing context". https://github.com/whatwg/html/pull/6315 is the relevant HTML issue. I'll file an issue on the BiDi spec to clarify this (might suggest changing the module and command names to match).
Updated•2 years ago
|
Reporter | ||
Comment 5•2 years ago
|
||
Tests for stale elements
have already been updated on bug 1772484. Now there is the question regarding no such element
errors. Given the WebDriver classic PR to move the element cache to the Window I wonder if this bug is still needed and has to be further discussed at all.
Bug 1692468 will make the change in Firefox to have the element cache hold by the Window (JSWindowActor) and bug 1774182 will improve all wdspec tests for the no such element
error checks. Maybe we can close this bug as dupe of bug 1774182?
Updated•2 years ago
|
Description
•