Emulation: Support geolocation override

[jimevans]

One request often heard from users is that they want to simulate a browser at a specific geolocation for their sites. WebDriver should provide a mechanism to facilitate this testing.

[whimboo]

Thank you @jimevans for filing!

I want to add that clients should be able to set this location override per tab.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Geolocation emulation.

The full IRC log of that discussion

<jgraham> Topic: Geolocation emulation
<jgraham> github: https://github.com//issues/343
<orkon> q+
<jgraham> jgraham: We know there are requests for this and Puppeteer has it, so this should be the next priority for emulation and overrides
<jgraham> ack next
<jgraham> orkon: We support this in puppeteer. The blocker for using this in BiDi is that we need to be able to provide permissions. It might be possible to use a preload script to override things, but I'm not sure.
<jgraham> q?
<jgraham> jgraham: I assumed we'd just provide mock data, does that require implementing permissions?
<jgraham> orkon: To request geolocation data you first have to give permissions. We could say that providing the data atuo-grants the permissions, but it might make sense to do permissions first, if that's needed cross-browser.
<orkon> q+
<JimEvans> q+
<jgraham> jgraham: Makes sense. We can do the work in parallel though; browsers might have some out of band way to disable the permissions prompt so you could still test that the right geolocation data is returned without supporting the permissions API.
<jgraham> ack next
<jgraham> orkon: Perhaps there is also a relation to the user prompt handing changes; permissions are like user prompts and we could have similar auto-accept functionality.
<jgraham> ack next
<jgraham> JimEvans: Does the permissions spec have a BiDi implementation?
<jgraham> orkon: We have it in Chrome, but I don't know about other implementations. It only covers overrides.
<jgraham> jgraham: We have the permissions spec implemented in classic, but not yet for BiDi (need to check which parts are actually shipping already)
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-webdriver-minutes.html jgraham
<jgraham> zakim, bye
<Zakim> leaving. As of this point the attendees have been AutomatedTester_, orkon, jdescottes, whimboo, jgraham, sasha, MaksimSadym, JimEvans, lightning00blade
<sasha> orkon: `browsingContext.setViewport` command already has a step to check if a specified context is a top-level context, and throw an error if it's not, so we don't need to do anything for iframes
<jgraham> RRSAgent: bye
<RRSAgent> I see no action items

[OrKoN]

Should we propose it as part of the https://w3c.github.io/geolocation-api/ spec?

[OrKoN]

Chrome currently supports latitude, longitude, accuracy overrides which works for the top-level context and iframes. It does not affect the permission and it does not allow to use geolocation on insecure contexts.

[christian-bromann]

WebdriverIO currently already supports this by overwriting the navigator.geolocation interface in the browser via the preload script:

const patchedFn = options instanceof Error
    ? `cbError(new Error(${JSON.stringify(options.message)}))`
    : `cbSuccess({
        coords: ${JSON.stringify(options)},
        timestamp: Date.now()
    })`
await this.scriptAddPreloadScript({
    functionDeclaration: /*js*/`() => {
        Object.defineProperty(navigator.geolocation, 'getCurrentPosition', {
            value: (cbSuccess, cbError) => ${patchedFn}
        })
    }`
})

[OrKoN]

@christian-bromann Thanks for sharing! Do you support changing it after the page is loaded/during the test? Also, what about Geolocation.watchPosition()?

I think the override on the browser side would be more robust but preload scripts offer the ability to implement something already.

[christian-bromann]

I agree. The current emulation features we have can't be changed after the page has loaded. It would be helpful, especially for component tests to modify these capabilities without having to do a page load.

[whimboo]

Note that there is an open PR for the geolocation spec for WebDriver integration: w3c/geolocation#170

[whimboo]

And here are the minutes from yesterday's joined meeting with the WebApplication group.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed emulation - geolocation.

The full IRC log of that discussion

<AutomatedTester> topic: emulation - geolocation
<jgraham> q+
<jgraham> https://pr-preview.s3.amazonaws.com/w3c/geolocation/pull/170.html#automation
<AutomatedTester> github https://github.com//issues/343
<AutomatedTester> github: https://github.com//issues/343
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: geolocation is a special case. THe webapps group have created an extension for this command. THere are a few issues but we can take their PR and put it directly into our spec
<sadym> q+
<AutomatedTester> ... and since we're putting emulaton directly into our spec that we take theirs and merge it and have that as a starting point for our discussions
<AutomatedTester> ack sadym
<jgraham> s/and merge it/and create a PR/
<AutomatedTester> sadym: when you say putting these into our spec are we going talking about the earlier topic or something else
<orkon> q+
<sadym> q+
<AutomatedTester> jgraham: like viewport is an emulation but I see what you mean
<AutomatedTester> ack orkon
<simonstewart> q+
<jgraham> q+
<AutomatedTester> orkon: I wonder if this would be better in the geolocation spec so that it maintained as a whole rather than in this spec?
<AutomatedTester> ack sadym
<AutomatedTester> sadym: if we keep the geolocation in the geolocation spec where should the other emulatons live?
<AutomatedTester> gsnedders: did the old JSON wire protocol handle geolocations?
<AutomatedTester> simonstewart:
<AutomatedTester> ... no it didn't... yay past ys
<AutomatedTester> ack simonstewart
<AutomatedTester> simonstewart: if geolocation are happy of this being an extension we should encourage to them to keep it since they have a better understnading
<gsnedders> s/what people want and the implementations might not work at user context/how people are actually using this; developers might not actually run into the differences here because most testing situations only have a single test running at a time, so maybe it doesn't super matter how we define this?/
<AutomatedTester> ... and to sadym question we should keep things where possible as close to the owners of that area
<gsnedders> https://www.selenium.dev/documentation/legacy/json_wire_protocol/#sessionsessionidlocation sure makes it seem like there was some command in the legacy protocol to change geolocation, though idk if there were implementations; it seems like safaridriver never did?
<whimboo> q+
<AutomatedTester> ... if we could keep webdriver super simple that would be awesome
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: it is essentially true that we could have this across all different specs
<AutomatedTester> ... but other specs have issues around our "stability"
<AutomatedTester> ... I just feel like it being a core feature for us it should be in our spec
<AutomatedTester> ... if we know about automation frameworks want this then it should be our spec
<AutomatedTester> simonstewart: how do you figure out where this would work in ours or there?
<jimevans> q+
<AutomatedTester> jgraham: I don't think it will change how things are implemented
<AutomatedTester> ack whimboo
<orkon> https://w3c.github.io/webdriver-bidi/#external-specifications
<AutomatedTester> whimboo: we already have an issue open to list external specs that are extending webdriver
<gsnedders> q+
<AutomatedTester> ... and we don't have anything for pulling in and generating the cddl specs
<sadym> q
<sadym> q+
<AutomatedTester> ... so we ould need to implement that
<AutomatedTester> ack jimevans
<AutomatedTester> jimevans: to echo what whimboo is saying. As a client side implementor it can be difficult to figure out where things have been implemented
<AutomatedTester> ... this is a problem in the classic and bidi spec. we try maintain the list but this is not always viable
<AutomatedTester> ... I am more inclined to keep things in 1 place to help create better client bindings
<AutomatedTester> q?
<AutomatedTester> ack gsnedders
<AutomatedTester> gsnedders: there is a project called webref that contains things that it knows about the idl/cddl/properties
<AutomatedTester> ... we could speak to them to get this implemented for us
<gsnedders> s|idl/cddl/properties|WebIDL/CSS Properties|
<AutomatedTester> q?
<whimboo> i just filed https://github.com//issues/791 to get our cddl file generation to care about external definitions
<gsnedders> s/get this implemented/get extracting CDDL implemented/
<AutomatedTester> ack sadym
<jgraham> q+
<AutomatedTester> sadym: where is the line for things should live is I think it should be "Is this in classic?" if it is not then it should not live in bidi since it is a new way of doing things and other things should be in their respective homes
<AutomatedTester> ack jgraham
<orkon> q+
<AutomatedTester> jgraham: I think if that is the line then we are already breaking that with network interception and a few others. Practically following that will move it hard for us to complete things... e.g. getting Fetch to do the network intercept stuff
<AutomatedTester> ... our spec has been cases of are they willing to handle the potential extra work load
<AutomatedTester> ... we also have not been good enough of reviewing things. e.g. geolocation have followed permissions who were doing the wrong things with using webidl
<AutomatedTester> ... centralisation has a lot of advantages
<AutomatedTester> ... I don't mind it being in geolocation, it just felt a little easier
<AutomatedTester> q?
<AutomatedTester> ack orkon
<AutomatedTester> orkon: I think would be great if the experts on their spec contribute to the testing part too
<AutomatedTester> ... but I don't have a very strong opinion here... also the tooling problem can be solved so not concerned by that
<AutomatedTester> q?
<orkon> present-
<gsnedders> Filed https://github.com/w3c/webref/issues/1353 for webref, FYI.
<gsnedders> jimevans is mentioning https://github.com/w3c/webauthn/issues/2072 in the room, about the response from nsatragno on the issue, and who should do the work to migrate the WebAuthn stuff to BiDi.
<gsnedders> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/09/26-webdriver-minutes.html gsnedders