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

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Marcus Bulach <bulach at chromium.org>  2010-05-04 03:31:09 PST ---
(In reply to comment #6)
> (From update of attachment 54801 [details])
> > +        This prevents a page requesting permission when it has just accessed navigator.geolocation (without calling navigator.geolocation.getGeolocationPosition).
> Did you mean navigator.geolocation.getCurrentPosition/watchPosition?

duh! :) fixed.

> 
> > +    m_startUpdatingRequested = true;
> Don't you also need to set this to false in stopUpdating() to prevent
> superfluous permission requests after all location requests have stopped?
> 
> If a call to navigator.getCurrentPosition/watchPosition is successful, then
> permission must have been granted by the time stopUpdating() is called, so
> there's no problem. However, if the service returns an error, or JavaScript
> cancels the location request before the service returns anything, then there
> will be no location requests in progress and no permission request will have
> been made. With the current patch, m_startUpdatingRequested will still be true
> so subsequent calls to setLastPosition() due to activity in other frames will
> wrongly trigger a permission request.
> 
> Or does the browser process already have logic to prevent this?
> 
> Maybe it's better to modify the browser process to only broadcast location
> information to bridges that have called startUpdating() but not stopUpdating(),
> as you suggest in the Chromium bug?

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 think I can solve both bugs here rather than in the browser side, let me try
a different change and will update soon.

thanks again for raising this!

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