Add test automation support via Web Driver #170
Conversation
marcoscaceres
changed the title
|
@reillyeon, this is pretty rough and probably pretty buggy... but it's at start. 😅 @rakuco, as you've got some experience in the area, would you mind also having a look? 👀🙏 |
| |target|'s [=relevant settings object=]'s [=global object=]'s | ||
| [=Window/browsing context=] to: | ||
| <ol> | ||
| <li>If |coordinates| is not given, clear the system location |
There was a problem hiding this comment.
We should define "system location" in a way that ties into the "acquire a position" algorithm.
There was a problem hiding this comment.
I thought about this as I was specifying this, but I think we might want keep them separate.
I initially tried to hook into "acquire a position"... but I think it might be best to keep them separate: this algorithm just sets the coordinates for the entire user agent*, then the actual API methods "acquire a position".
*at least initially... let's start simple and then see if we need to set it per origin. That adds a lot of complexity thought, so we probably don't want to do that.
There was a problem hiding this comment.
I think it's as easy as saying, "a top-level traversable has a mock position which is initially unset". This algorithm sets the mock position and the "acquire a position" algorithm checks if the mock position is set in step 5.3.3.
There was a problem hiding this comment.
Ok, yeah, I like that the mock position to take precedence over the system one... and it doesn't imply that it's touching the system one at all (it's just something that works with automation and that's it).
| To <dfn>set the system coordinates</dfn> given an optional | ||
| {{GeolocationMockCoordinates}} | ||
| |coordinates:GeolocationMockCoordinates|, and an optional [=user | ||
| agent=] |agent|: |
There was a problem hiding this comment.
I'm still working on understanding the WebDriver BiDi architecture but in the old WebDriver specification requests have a session from which you can derive the browsing contexts to which a command will apply. Rather than applying to the entire user agent this allows automation to control only the specific context the developer is targeting.
There was a problem hiding this comment.
yeah, something like that could work... I'll see how this looks in the implementation and hopefully can base it off that.
There was a problem hiding this comment.
As mentioned in #146, Chromium already implements this in the Chrome DevTools Protocol and it is scoped to a particular browsing context. This interface is used by Chrome DevTools to provide a UI for setting a mock position. It would be weird if a change made while inspecting one page affected other pages as well. Supporting both page-level and browser-level location overrides would introduce a lot of complexity to the implementation.
There was a problem hiding this comment.
Agree... that would be weird.
Co-authored-by: Reilly Grant <reillyeon@users.noreply.github.com>
Closes #146
The following tasks have been completed:
Implementation commitment (and no objections):
Documentation (new feature):
For documentation, either create an issue or pull request in MDN's Content repo - providing as much information as you can. PR is prefered.
Preview | Diff