Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
Also, the word position is used to represent a tree-position in DOM in WebKit so please don't use that to represent a point in a screen or a layout coordinate system. OK, perhaps we should use Vector2d, as is used by the Chromium port ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I've uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=106408 which replaces these subtraction operators with ones that return xxxPoint, and which adds Int/FloatSize::fromCornerPoints(). The patch does just enough to make these changes, though in many cases, the switch from xxxSize to xxxPoint could be propagated further up and down the stack. However, the patch is probably big enough as it is, so this should probably be done separately, on a case-by-case basis. Note that the patch isn't ready for formal review, but I wanted to get some feedback before I pursue it further. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
I'm really not sure that this set of changes is going in the right direction. What's driving them; some abstract sense of purity, or reducing the chances of introducing real bugs that we've seen in the past? Some of both. I was investigating a bug where WebCore is generating unexpected negative sizes. While looking into how this could happen, I noticed that in some cases, negative sizes result from size types being used to represent things that seem more like points. It seems like it would be good to clean this up this misuse of size types, and perhaps in the long term, we can avoid negative sizes altogether, which would help avoid these kinds of bug in the future. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
It seems like a lot of churn for relatively little gain. I'd rather our time be focused on areas that actually benefit users of WebKit. OK. I don't feel strongly enough about this to push the issue. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. Introducing the concept of a vector could then be done in a second phase. WDYT? Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
I find point - point = size quite useful in general, and it seems to make logical sense. I agree that it makes logical sense, but I think that 'point - point = point' also makes sense, and is perhaps more frequently the right choice. What would you call this type, avoiding confusion with Vector? I guess 'Offset' is an obvious candidate, but that is probably already too overloaded. Perhaps RelativePosition or RelativePoint? On 4 January 2013 16:15, Simon Fraser simon.fra...@apple.com wrote: On Jan 3, 2013, at 7:43 PM, Steve Block wrote: Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I find point - point = size quite useful in general, and it seems to make logical sense. Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Int/FloatPoint and Int/FloatSize
Hi webkit, I was hoping that somebody could clarify the policy regarding the correct use of Int/FloatPoint vs Int/FloatSize. It seems that xxxPoint is consistently used to represent a position, which makes sense. However, when representing the position of one point relative to another, both xxxPoint and xxxSize are used, which seems inconsistent. I'd expect that xxxPoint should be used for this case of a relative position, since its x(), y() and length() methods make more sense than the width() and height() methods of xxxSize. However, the operators [1] for subtracting one xxxPoint from another encourage the use of xxxSize. I recognize that in some situations, you need really do want to represent the difference between two points as an area or size, but this seems the less common case, and it might be better to make it more explicit [2]. My questions are ... - What (if any) is the correct policy? - Would people welcome changes to encourage that policy? Thanks, Steve [1] eg 'inline FloatSize operator-(const FloatPoint, const FloatPoint)' [2] Perhaps something like 'static FloatSize FloatSize::fromCornerPoints(const FloatPoint, const FloatPoint)'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Early deletion of DocumentLoader instances
It looks like this was resolved in https://bugs.webkit.org/show_bug.cgi?id=61494, which resulted in http://trac.webkit.org/changeset/87756. I can't access the bug, so I'm following up here ... This change is causing problems on Android. We use the AllowLocalLoadsForLocalAndSubstituteData policy but Document::initSecurityContext() no longer calls securityOrigin().grantLoadLocalResources() because of the check for 'm_frame-document() == this' added by this change in DocumentLoader::loader(). In DocumentWriter::begin(), we create a new Document, and the Document constructor calls Document::initSecurityContext(). However, at this point the Frame has not yet been updated with the new Document, so we fail the new check in DocumentLoader::loader(). However, it looks like the Frame does have the correct DocumentLoader at this point. So it seems wrong for Document::loader() to return 0 and seems that the new check isn't valid in all cases? Or am I missing something? Any advice would be greatly appreciated. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remote Debugging v8 - Android
You need to check with Android port owners on whether they intend to enable INSPECTOR in their builds and expose remote debugging capabilities. I'm afraid we have no plans right now to enable this feature. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Client-based Geolocation
(1) Adds a level of indirection that may not be necessary in these cases. It's true, there's now one more level of indirection. The non-client-based implementation uses Geolocation - GeolocationServiceFoo. The client-based implementation uses Geolocation - GeolocationController - GeolocationServiceFoo. I don't think this is significant, especially as the Controller/Client pattern is well established. (2) Harder to find the back end code, since the common pattern is to have platform-specific implementations in WebCore/platform True, though as I mentioned previously, I'm not sure that Geolocation really fits into the category of 'platform-specific implementations' - there are too many decisions to be made by the embedder. (3) There may not be a one-to-one mapping between back-end implementations and WebKit public APIs. So far, there is a one-to-one mapping. My argument is that this likely to remain the case because embedders want to have close control over their Geolocation implementation (for example, when to enable a GPS if present, which URL to use for network-based lookups, how to handle position caching, how frequently to poll for updates etc). While it might be possible to have a GeolocationServiceLinux in WebCore/platform/linux, for example, that would provide position information for all Linux-based ports, I think that in practice, the embedder wants to have more control than this approach permits. So I think there will be little, if any code duplication between ports. If we later find that multiple ports are duplicating code by using a common platform library, for example, we could consider adding a shared WebCore utility to provide access to this. So that explains the upsides, but you didn't address the downsides I cited. Sorry, I hope I've done so now. Maybe the positives outweigh the negatives, Yes, that's exactly my opinion. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Atomic read/write operations and thread safety
I have a question about whether WebCore code makes assumptions about the atomicity of certain read/write operations. The particular instance I'm interested in is IconDatabase, where m_threadTerminationRequested is written to from the main thread (in close() for example) and read from the DB thread (in syncThreadMainLoop()) without any locking. It looks like the code is written such that there's no particular synchronization requirement in terms of the order in which the value is set and read. But there's a risk of a garbled read in the case of a simultaneous read and write from the two threads. I assume that the lack of locking is an intentional decision, based on the fact that on all relevant architectures, a boolean read/write is atomic? Is this a general WebCore policy? It would be great if somebody could confirm this, or point out why I'm wrong. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Atomic read/write operations and thread safety
The boolean in question isn't both checked and set at the same time - it's not an acquired resource. One thread sets it, the other checks it. I don't follow. If it's set from one thread and checked from another thread without locks, how can you guarantee this (other than with application logic)? I don't understand your question - how can you guarantee this? I meant 'how can you guarantee that the boolean isn't both checked and set at the same time, given that you don't use locks'. But it looks like you're saying that this is guaranteed by higher-level application logic, as you describe below. It doesn't matter if it's written and read at the same time in this case - but after every write on the main thread, the background thread is signaled to read, so that read will always happen after the write. OK, makes sense. Thanks, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Atomic read/write operations and thread safety
Thanks for the reply Brady. The boolean in question isn't both checked and set at the same time - it's not an acquired resource. One thread sets it, the other checks it. I don't follow. If it's set from one thread and checked from another thread without locks, how can you guarantee this (other than with application logic)? Additionally, while there isn't a guard specifically around the boolean, there is the m_syncLock Mutex which is implicitly guarding operations on this bool, so the thread safety of a bool? argument becomes somewhat moot. Ah, so you're saying that there's application logic using m_syncLock to prevent the boolean from being written and read at the same time? I didn't spot that. I have seen this particular technique quite often before. The only thing one needs to watch out for is to declare such a boolean volatile (which I believe this code does, if memory serves). Otherwise the thread which polls the condition may read from a cached location and miss the change. The boolean in question isn't volatile. This isn't a problem because as I mentioned, there's no requirement for a given write to be picked up by a particular read. If a read 'misses' a write, we'll pick it up later. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are the mock implementations in WebCore/platform?
Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. I added the first mock class, GeolocationServiceMock , to allow Geolocation to be tested in LayoutTests. At the time, the (non-client-based) Geolocation implementation lived in WebCore/platform, so it was suggested I create a new mock directory - https://bugs.webkit.org/show_bug.cgi?id=28264#c5. Since then, new mocks have been added to the same directory. However, these newer mock classes, such as DeviceOrientationClientMock, are for client interfaces, so I agree that it no longer makes sense for them to live in WebCore/platform. This includes GeolocationClientMock, which is the mock for the newer client-based Geolocation implementation to which we are in the process of switching - https://bugs.webkit.org/show_bug.cgi?id=40373 I'm not sure why you'd want to mock out a client interface. Can't you just implement the client interface in DRT? The idea behind the mocks for the client interfaces is to provide shared code which can be used by all ports' implementations of DRT to give reliable behaviour for LayoutTests. Perhaps a top-level WebCore/mock/ would be preferable. That sounds reasonable, or perhaps WebKit/mock, as these are implementations of WebCore client interfaces to be used by DRT. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Client-based Geolocation
On the one hand, getting rid of ifdefs is good. On the other hand, it seems to me there are some downsides to moving ports over to the client-based approach: The motivation is much more than removing ifdefs. The original Geolocation implementation was provided in WebCore/platform, presumably because it was seen as a platform-specific abstraction to hardware sensors. However, embedders require close control over the behaviour of Geolocation because there are lots of UA policy decisions to be made (eg handling user permissions, when to use network location vs GPS, when to suspend GPS to save power - https://bugs.webkit.org/show_bug.cgi?id=34082 etc). Trying to do this with the non-client based architecture caused layering violations, so the client-based implementation was added - https://bugs.webkit.org/show_bug.cgi?id=32499 - which gives embedders complete control over Geolocation. Since then, trying to maintain two versions of Geolocation has proved cumbersome, so I think it makes sense to switch completely to the client-based approach. For reference, the top-level bug for client-based Geolocation is https://bugs.webkit.org/show_bug.cgi?id=40373 Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK Skiplist
I think the code review in which the need to do this was first pointed out to me was https://bugs.webkit.org/show_bug.cgi?id=27716#c32 I've been following this pattern for the Geolocation and DeviceOrientation tests, all of which are skipped on GTK. If I can instead list the directory, that would mean one fewer file to modify each time a new test is added. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page
- it would allow the client to live in WebCore. FWIW, Geolocation seems to take both approaches. One implementation is down in Navigator/Document/DOMWindow, but the mock controller is on Page. I've found the low-level approach much easier to implement. My understanding was that clients for these platform-specific features should live in the WebKit layer. The original Geolocation implementation used a platform-specific GeolocationService in WebCore, but a client-based implementation was later added by Sam to avoid the layering violations of the former approach. See https://bugs.webkit.org/show_bug.cgi?id=32499#c10. I'm currently working to remove the old non-client-based Geolocation implementation, see https://bugs.webkit.org/show_bug.cgi?id=40373. Please let me know if this is the wrong approach! I assume one of the advantages of having them on Page is that it allows a Mock Controller to be easily created for testing from Dump Render Tree. Am I right? Is this that important? Yes, that is also part of the motivation. The non-client-based Geolocation implementation provides a mock in WebCore, but setting and configuring this mock from DumpRenderTree is ugly. For this sort of thing, it seems reasonable to me that there is a layer of the implementation that is a per-document controller, and then below that a singleton object in case we don't need things to happen multiple times per document. I don't have a strong opinion regarding Page vs Document, but it seems that other platform-specific clients of this type belong to the Page. I agree that it's likely that a platform will use a singleton at the lowest level, but the platform can provide the multiplexing whether the client is provided to the Page or the Document. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
I'd be happy to help where I can too, and can migrate the existing Geolocation/DeviceOrientation/SpeechInput mocks to use the new pattern. Please CC me on any bugs you create. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. There might still be the need for some plumbing though. In the case of DeviceOrientation and SpeechInput, we're mocking a client which is provided by WebKit. Even though the mock implementation happens to live in WebCore, it's instantiated and owned by the WebKit layer. So in order for LayoutTestController to configure the mock (eg layoutTestController.setMockOrientation(...)), we need to route calls from the WebCore LayoutTestController up to WebKit. I guess you could use a new LayoutTestControllerClient. I think you're right though that this could be done without the need for type conversions, as none of this is exposed in the WebKit API. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Sharing WebKit mocks across platforms
I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
https://bugs.webkit.org/show_bug.cgi?id=42834 has now been r+'ed. I'll submit in the morning if there are no further comments. Thanks, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
I've filed https://bugs.webkit.org/show_bug.cgi?id=42834 to track the addition of a structure to pass pointers to the clients for optional features. Feedback welcome. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Clients and the Page constructor
Currently, nine clients are passed to the Page constructor and the number is growing. Recently, clients have been added for Geolocation, DeviceOrientation and BackForwardController. This approach doesn't seem scalable. Instead, I'd like to suggest that clients, at least those for optional features, are not passed to the Page constructor. Instead, the client should default to null and can be set with an explicit method call, eg page-setFooClient(client) or page-getFooController()-setClient(client). This is the approach that was taken for SpeechInput in http://trac.webkit.org/changeset/63230. If there are no objections, I'll send patches to make this change for Geolocation and DeviceOrientation. For reference, see the discussion in https://bugs.webkit.org/show_bug.cgi?id=39589. Thanks, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
What exactly does not scalable mean? Passing arguments to the constructor rather than setting them up later is often good because there is no time window where the object is not set up. Generally speaking we don’t want to have to write code to handle a client of 0 unless it’s absolutely necessary. Agreed. My motivation was to avoid the long, growing, list of arguments and to avoid the need to update the call sites for all platforms with an extra '0' each time a new optional feature is added. Another option, if the objection is a function with a lot of arguments, is to pass in a structure with all the client pointers to the constructor. That sounds reasonable. A structure of the client pointers for all optional features, with each entry defaulting to 0, would solve this problem. Another argument for the setter is that it makes it easier to inject a mock for testing in response to a LayoutTestController method call, by simply calling the setter again to replace the real client with a mock client. Personally, however, I think that this is somewhat abusing the idea of setting a client. If the real implementation needs to be switched for a mock at runtime in DRT, this should probably be handled by the client itself - so the same client is used throughout the lifetime of the Page. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
That still makes it required to add null checks for some (or all) of the clients. Something we've avoided in the past. This wouldn't add a need for null checks. The structure would only be for clients for optional features. If the feature is enabled, the client must be non-null. This is no different from the case with the individual arguments used currently. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Multiple location providers in Geolocation API
Well that platform should manage between GPS and any other providers itself? So if this was implemented on iPhone, for example, the platform uses iPhone's CoreLocation, and it manages where it is getting the data from itself. That is a platform detail as I read it. Sure, I agree. On a related note, each time a new request is made, the PostionOptions for that request are passed to the GeolocationService by calling startUpdating(PositionOptions*). This allows the GeolocationService to estimate which location sources are needed (ie whether GPS is to be used) for all currently executing requests. However, this will always be an upper bound, as there's no way to remove sources from the list. Again, is this intentional? Even if we choose to share the results of all providers between all currently active requests, I think we should still limit the use of 'enableHighAccuracy' providers to times when a request specifying this option is in progress. In the current implementation, once a request has been made with enablehighAccuracy=true, all subsequent requests will use the 'expensive' providers, until all current requests have completed. What do you think? I think that is a question for the GeoLocation list, in fact I think it may have been covered there? I don't think it has been covered there, but this is an implementation detail I think. I think that should be left up to the platform, personally. In a theoretical iPhone platform, CoreLocation will be as accurate as the most accurate request, maxing out with the accuracy the device is capable of. Sure, but the present code does not pass the necessary information to the platform-specific GeolocationService. So an implementation is not able to limit the use of high-accuracy providers to times when a request that specifies enableHighAccuracy is in progress. In order for the platform-specific implementation to decide on a policy, we need to pass to the GeolocationService both the 'registration' and 'unregistration' of enableHighAccuracy-enabled requests. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
