Bug 38195 – Bring CLIENT_BASED_GEOLOCATION more in line with non-client based: remove Geolocation::setPosition and use lastPosition()

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Marcus Bulach]

Non-client based geolocation uses "lastPosition()" rather than storing via "setPosition()".
Client-based should have a similar mechanism.

[Marcus Bulach]

Created attachment 54413 [details]
Patch

[Marcus Bulach]

Hi Steve,

This is a follow up on https://bugs.webkit.org/show_bug.cgi?id=36315, thanks for the clarification!

Would you mind taking a look please?

[Darin Adler]

Comment on attachment 54413 [details]
Patch

The whitespace changes in the patch are far larger than the substance of the patch.

Does this change behavior? Is there a way to test this?

[Steve Block]

Comment on attachment 54413 [details]
Patch

> - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
I think it's best to leave the whitespace changes out of this patch for clarity.

> +    if (m_lastPosition.get())
> +        return m_lastPosition.get();
Is this caching required for correct behaviour or is it just an optimisation? GeolocationController::lastPosition() should only be called once the client has called GeolocationController::positionChanged(), and it seems that the client should always have a last position available by this time.

[Marcus Bulach]

Created attachment 55031 [details]
Patch

[Marcus Bulach]

(In reply to comment #3)
> (From update of attachment 54413 [details])
> The whitespace changes in the patch are far larger than the substance of the
> patch.

yep, sorry about that: my editor insisted in removing all trailing ws. :(
the latest patch is less invasive.

> 
> Does this change behavior? Is there a way to test this?
it's just a minor refactoring as suggested by Steve at https://bugs.webkit.org/show_bug.cgi?id=36315
there should be no changes in behavior.

[Marcus Bulach]

(In reply to comment #4)
> (From update of attachment 54413 [details])
> > - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
> > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> I think it's best to leave the whitespace changes out of this patch for
> clarity.
yep, reverted the ws changes.

> 
> > +    if (m_lastPosition.get())
> > +        return m_lastPosition.get();
> Is this caching required for correct behaviour or is it just an optimisation?
> GeolocationController::lastPosition() should only be called once the client has
> called GeolocationController::positionChanged(), and it seems that the client
> should always have a last position available by this time.

AFAICT GeolocationController::m_client is optional, which means we need to hold on the position passed via the public method GeolocationController::positionChanged(GeolocationPosition* position), that is, this method may be called directly without a client.

I'm not entirely familiar with this part, so please, let me know if I'm wrong, or who else could help taking a look at it!

[WebKit Commit Bot]

Comment on attachment 55031 [details]
Patch

Clearing flags on attachment: 55031

Committed r59216: <http://trac.webkit.org/changeset/59216>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.