Created attachment 157683 [details] Geolocation extension APIs It would be nice to have third party dev tools extensions built using location aware services. Once the location override APIs are exposed (considering all the necesarry permissions/security considerations), it would provide intuitive interface through which the web developers can verify their location aware services/apps. I am attaching the mock UI for demonstration purpose.
I would be glad to receive comments on the said feature before commencing actual work.
So we are essentially talking about the third party chooser for the location? I would be open to it. But it sounds like a minor feature to me, while the API will be there forever. I wonder if clients should use the protocol instead.
(In reply to comment #2) > So we are essentially talking about the third party chooser for the location? Yes its about third party chooser. > I would be open to it. But it sounds like a minor feature to me, while the API will be there forever. Are you referring to extension API or the one introduced by http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json#L355 in 89365? > I wonder if clients should use the protocol instead. I was considering it on the similar lines of chrome devTools extensions API. Is there a different process followed within the webkit for the extension APIs?
Chrome's devtools extensibility is based on the front-end's one, it is leaving upstream. I was referring to the http://developer.chrome.com/extensions/debugger.html that exposes the function in json you are pointing to (many WebKit-based browsers expose inspector protocol these days).
I.e. there already is a way to implement such a chooser, but it is based on non-public protocol API.
(In reply to comment #4) > Chrome's devtools extensibility is based on the front-end's one, it is leaving upstream. I was referring to the http://developer.chrome.com/extensions/debugger.html that exposes the function in json you are pointing to (many WebKit-based browsers expose inspector protocol these days). Oh thats great. I was not aware of this. Thank you! (In reply to comment #5) > I.e. there already is a way to implement such a chooser, but it is based on non-public protocol API. In that case we don't need to have this bug for exposing such an API. Only concern could be non-public API but considering the current experimental state of geolocation override, it would be difficult to draft a public API. Please let me know if you think otherwise.
> In that case we don't need to have this bug for exposing such an API. Only concern could be non-public API but considering the current experimental state of geolocation override, it would be difficult to draft a public API. Please let me know if you think otherwise. I agree. One additional note is that there can only be one instance of the protocol client attached. So whenever your protocol client emulates the location, devtools / inspector window can't be used.
Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.