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.
The timeout timer of a geolocation request holds a strong reference to
the request. This can cause the window to leak if the request is not
completed before the tab containing the window is closed.
To fix this, I made the timer instead hold a strong reference to a
wrapper class that has only a weak reference to the request. The
request destructor must now cancel the timeout timer.
I also outlined a call to StopTimeoutTimer() in
nsGeolocationRequest::Shutdown().
The timeout timer of a geolocation request holds a strong reference to
the request. This can cause the window to leak if the request is not
completed before the tab containing the window is closed.
To fix this, I made the timer instead hold a strong reference to a
wrapper class that has only a weak reference to the request. The
request destructor must now cancel the timeout timer.
I also outlined a call to StopTimeoutTimer() in
nsGeolocationRequest::Shutdown().
Add the wake lock api to geolocation.
If your app holds a lock, you can continue use geolocation service when your app is invisible.
Otherwise, your invisible app can't get any updated location.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
