Better integration with testing framework

[marcoscaceres]

Mostly editorial, but was thinking we might want to add some kind of position-changed slot to better integrate with the testing framework... that can serve as the trigger for sending out a new position (this would work for any/all position changes, not just for the testing framework).

Was thinking we could store the position and then check on the turn of the event loop or something (and clear/cache it as needed). That way we can set up a bit of a "push" model, where the OS notifies the user agent of the change, and then the user agent can use it once the right conditions are met.

[marcoscaceres]

Ok, yeah... looking at the emulation part... we can probably get rid of the "get emulated position"... if the position is emulated is not relevant to reporting the position. It's a potentially nice feature that it's indistinguishable from a "real" position.

We really just want to set the new position, the user agent goes "ooh!! new shiny position!" and queues then just runs the appropriate steps.

[reillyeon]

I agree, I think that would simplify a bit of the logic. We probably still need to distinguish between data sources when requesting a position update, but we can handle the update with unified code.

[marcoscaceres]

We probably still need to distinguish between data sources when requesting a position update

Can you help me understand what you mean here? I'm wondering if what's actually needed here is to tell the browser to not use (or otherwise disable) "real" geolocation if set by automation - to avoid them from conflicting.

[reillyeon]

Discussed at TPAC 2025. Group resolved to make @marcoscaceres's proposed changes.