Bug 49921

Summary: [Chromium] Introduce WebPermissionController for client-based Geolocation
Product: WebKit Reporter: John Knottenbelt <jknotten>
Component: WebKit APIAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: fishd, steveblock
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch none

John Knottenbelt
Reported 2010-11-22 09:53:00 PST
These classes are helpful for the client-based geolocation implementation of ChromeClient::requestGeolocationPermissionForFrame and ChromeClient::cancelGeolocationPermissionRequestForFrame. The WebGeolocationPermissionController/Client convert the permission requests to be per security origin (from being per Frame).
Attachments
Patch (15.99 KB, patch)
2010-11-22 09:56 PST, John Knottenbelt
no flags
John Knottenbelt
Comment 1 2010-11-22 09:56:35 PST
Darin Fisher (:fishd, Google)
Comment 2 2010-11-22 16:19:05 PST
Comment on attachment 74568 [details] Patch It's not clear how these interfaces interact with the rest of the API. How do you get a WebGeolocationPermissionController? Also, why do we need more geolocation interfaces to be implemented by the embedder? Why isn't it enough to just have one interface that the embedder should implement for geolocation stuff?
John Knottenbelt
Comment 3 2010-11-24 08:52:09 PST
Discussed with Steve, and decided to change the approach on this. Instead of having a WebGeolocationPermissionController, will bring permission management under the Geolocation Client/Controller.
John Knottenbelt
Comment 4 2010-11-25 03:14:57 PST
See also https://bugs.webkit.org/show_bug.cgi?id=50061 which is the change to bring permission control into the GeolocationClient.
John Knottenbelt
Comment 5 2010-12-13 06:09:14 PST
Geolocation permissions are now handled by GeolocationClient, which makes this class unnecessary.
Note You need to log in before you can comment on or make changes to this bug.