- From: Marcos Cáceres via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Apr 2024 01:14:01 +0000
- To: public-geolocation@w3.org
> When building automation for sensors we found that having it "set" the sensor value makes it easier to write tests because the "echo" behavior is prone to race conditions. Wouldn't WebDriver BiDi account for the race conditions though? (honest question, I assume that's what "BiDi" was supposed to address) > The "set" semantics are also easier to define in terms of the existing specification algorithms as we can hook into the [acquire a position](https://w3c.github.io/geolocation-api/#dfn-acquire-a-position) steps with "Has an override value been provided, if so return it" rather than introducing language which has to check "are we trying to acquire position? If so, here's a value to return. Otherwise, throw it away?" I guess "set" works in both cases, so long as this works: ```JS navigator.geolocation.getCurrentPosition(console.log); await test_driver.setGeolocation(position); ``` My worry was that the above would break racy. If not, then "set" is totally fine. We should confirm that with Puppeteer just in case. Any chance you can do that? Otherwise I can try to find some time to quickly slap something together. -- GitHub Notification of comment by marcoscaceres Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/146#issuecomment-2046282262 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 April 2024 01:14:03 UTC