mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-18 07:45:30 +00:00
1bf6681a43
I think it is possible for the TimerCallbackHolder to fire off a Notify() while the geolocation object and the nsGeolocationRequest are only holding each other alive, so they would be freed by the cycle collector the next time it runs, but we haven't run the cycle collector yet. If that happens, then Geolocation::RemoveRequest() would break the cycle, causing stuff to unravel and bad things to happen. To fix this, we just hold the request alive in TimerCallbackHolder::Notify(), which will also ensure that the geolocation object is alive, hopefully preventing crashes. This will make the Notify() behavior similar to what it was before bug 1238427, when the nsITimer object would hold a strong reference to the request when the Notify() was being run. |
||
|---|---|---|
| .. | ||
| MLSFallback.cpp | ||
| MLSFallback.h | ||
| moz.build | ||
| nsGeoGridFuzzer.cpp | ||
| nsGeoGridFuzzer.h | ||
| nsGeolocation.cpp | ||
| nsGeolocation.h | ||
| nsGeolocationSettings.cpp | ||
| nsGeolocationSettings.h | ||
| nsGeoPosition.cpp | ||
| nsGeoPosition.h | ||
| nsGeoPositionIPCSerialiser.h | ||