[Webkit-unassigned] [Bug 38323] Prevents setLastPosition() before startUpdating() being called.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 10 10:13:45 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=38323





--- Comment #12 from Marcus Bulach <bulach at chromium.org>  2010-05-10 10:13:45 PST ---
thanks Steve! comments inline, another look please?

(In reply to comment #10)
> > that's a *very* good point, thanks for raising it! I didn't realize startUpdating / stopUpdating weren't balanced,
> > so the current implementation has a bug as it dettaches the bridge unconditionally on "stopUpdating"...
> I don't think that's a bug. Calls to startUpdating() and stopUpdating() from the Geolocation object are intentionally unbalanced. startUpdating() is called each time a new request (getCurrentPosition or watchPosition) is started. lastPosition() is only called when the last request is complete. See Geolocation::hasListeners().

I think I finally understood the flow, thanks for the clarification!
It turns out it's simpler than the original patches I proposed.
The original problem was that the bridge was being attached on the ctor, rather than on startUpdating, because requestPermission could be called without a corresponding startUpdating.

I added a new method "attachBridgeIfNeeded()", which seems to make things simpler and removed the flag / refcounting / guards around start/stop updating.

please, let me know if this makes sense.

> FWIW, this is something I'd like to change. Currently, the fact that stopUpdating() is called only once means that if a request is made with enableHighAccuracy=true, the GeolocationService will always use enableHighAccuracy=true for all future requests within the lifetime of the Geolocation object.
> 
> > as for the service throwing error condition: if i understood the flow correctly it will eventually call stopUpdating, right?
> Yes, that's right. If the call to startUpdating() fails, the notifier will call back to Geolocation::fatalErrorOccurred() which will call stopUpdating() if there are no longer any requests in progress.

ok, thanks! with the latest patch, stopUpdating remains unchanged.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list