495294 - error callback is invoked even when clearWatch is called.

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Doug Turner (:dougt)]

basically what is happening is

watch() is called.
clear() is called.

some time later
user cancels (or this could be immediately after watch).

error callback is invoked.


The spec states that once a watch has been cancelled with clearWatch(), the implementation should not invoke any callbacks.

Comment 1

[Tom Wuttke]

This was fixed as part fo the patch submitted in 596481.

Comment 2

[Wikiwide]

Fennec nightly, 2010-12-07, Maemo 5, Qt:
The bug isn't fixed.
When watch is cleared, GPS (locked or not) is disconnected (very good), and then later errorCallback (timeout) is invoked.

Comment 3

[Valentin]

I can still see this issue. I've created a dynamic grid to display all the props from the geolocation object and the only property/value that changes is the timestamp. Anyway, if the watch was cleared, it shouldn't trigger the call back even if  something changed.

Comment 4

[:garvan]

Based on:
https://dxr.mozilla.org/mozilla-central/source/dom/geolocation/nsGeolocation.cpp?from=NotifyErrorAndShutdown&case=true#398

The first line of that function should be if (mShutdown) return NS_OK.
However, I want to get a repro case first. Maybe a mochitest can be rigged up to reproduce this.

Comment 5

[Michelangelo De Simone [Offline] [:mds]]

(In reply to Garvan from comment #4)

> The first line of that function should be if (mShutdown) return NS_OK.
> However, I want to get a repro case first. Maybe a mochitest can be rigged
> up to reproduce this.

Correct.

If this is still happening a minimal test case would be very welcome.:)

Comment 6

[Alphan Chen [:alchen]]

(In reply to Garvan from comment #4)
> Based on:
> https://dxr.mozilla.org/mozilla-central/source/dom/geolocation/nsGeolocation.
> cpp?from=NotifyErrorAndShutdown&case=true#398
> 
> The first line of that function should be if (mShutdown) return NS_OK.
> However, I want to get a repro case first. Maybe a mochitest can be rigged
> up to reproduce this.

Bug 886026 add a mochitest case for ClearWatch which is introduced in the end of 2014.
Until now, we don't find similar bug.
I think we could monitor the result of mochitest for this symptom.