This change has two parts:
- Change //content to handle GeolocationService requests by calling the GeolocationServiceContext Mojo interface
- Change devtools to implement overriding the user’s location by calling the GeolocationServiceContext Mojo interface
Summary: Change //content to use GeolocationContext to support overriding geolocation on per-tab basis (was: Change //content to use GeolocationServiceContext to support overriding geolocation on per-tab basis)
Hi, Colin, My understanding on this task:
Currently each WebContentsImpl owns a GeolocationContext. After adding the GeolocationContext mojo interface, each WebContentsImpl owns a mojom::GeolocationContextPtr. So Devtools can get the raw pointer of the mojom::GeolocationContextPtr from WebContents to do the override-location.
Also, the GeolocationServiceImpl takes a raw pointer of mojom::GeolocationContextPtr instead of the device::GeolocationContext* as parameter in its constructor.
WebContentsImpl inits mojom::GeolocationContextPtr and creates the mojo connection in its constructor. In //device side, the GeolocationContext instance is strong-bound to the mojo connection.
If correct I'm going to start change code:)
Thanks.
And, Host the GeolocationContext by DeviceService. DeviceService is only responsible for strong-bindingly creating GeolocationContext, not care the deleting.
So the WebContentsImpl can connect Device Service to build the GeolocationContext mojo connection.
Yes, this sounds correct. It should be conceptually similar to how WakeLockContext works, which is in line with the understanding you're presenting here.
Comment 1 by blundell@chromium.org
, May 22 2017Labels: DeviceService OS-All
Status: Available (was: Untriaged)