Closed
Bug 731875
Opened 13 years ago
Closed 13 years ago
Geolocation doorhanger might cause a zombie compartment
Categories
(Core :: DOM: Geolocation, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jdm, Assigned: smaug)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink])
Attachments
(1 file)
(deleted),
patch
|
dougt
:
review+
|
Details | Diff | Splinter Review |
I see a zombie compartment from www.joshmatthews.net/position.html sitting in about:compartments, and I haven't visited that test page for more than a day. I'll try to find some time to try with a blank profile, as this one has lots of addons present.
Updated•13 years ago
|
Component: General → Geolocation
Product: Firefox → Core
QA Contact: general → geolocation
Updated•13 years ago
|
Blocks: leakychrome
Whiteboard: [MemShrink]
Comment 2•13 years ago
|
||
I had a similar thing happen on Google Maps. The documents ended up being held alive like so:
0x12a3e9000 [rc=6] nsDocument normal (xhtml) http://maps.google.com/maps (etc)
Roots: 1
0x132fa0f90 [rc=2] root nsXPCWrappedJS (nsIDOMGeoPositionOptions)
0x124cb5800 [rc=6] nsDocument normal (xhtml) http://maps.google.com/maps (etc)
Roots: 1
0x132fa0f90 [rc=2] root nsXPCWrappedJS (nsIDOMGeoPositionOptions)
Reporter | ||
Comment 3•13 years ago
|
||
It's very interesting that the nsIDOMGeoPositionOptions object is at fault here; it looks like we would have to be holding on to an nsGeolocationRequest object somewhere for that to be the case. That backs up my theory that the doorhanger is at fault, so we should be looking at http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1552 (which takes a request object and initiates a prompt that holds on to it) and http://mxr.mozilla.org/mozilla-central/source/toolkit/content/PopupNotifications.jsm#234 (which actually creates the prompt).
Reporter | ||
Updated•13 years ago
|
Component: Geolocation → General
Product: Core → Firefox
QA Contact: geolocation → general
Assignee | ||
Comment 4•13 years ago
|
||
I'm going to remove nsIDOMGeoPositionOptions
Reporter | ||
Comment 5•13 years ago
|
||
Here's my working theory: _refreshPanel (http://mxr.mozilla.org/mozilla-central/source/toolkit/content/PopupNotifications.jsm#386) creates extra menu items based on secondaryActions (that hold on to the request) that are only removed when showing another prompt. _remove (http://mxr.mozilla.org/mozilla-central/source/toolkit/content/PopupNotifications.jsm#351) doesn't remove these elements, so they can stick around for a very long time.
Product: Firefox → Toolkit
QA Contact: general → general
Assignee | ||
Comment 6•13 years ago
|
||
Need to still fix nsIDOMGeoPositionErrorCallback and nsIDOMGeoPositionCallback
handling, since those cause leaks.
Assignee: nobody → bugs
Attachment #615329 -
Flags: review?(doug.turner)
Reporter | ||
Comment 7•13 years ago
|
||
I strongly suspect that with this patch applied we'll just see other member objects of the request (such as the callbacks) causing the callbacks. I think we need to address comment 5 to fix all the possible leaks from the doorhanger.
Assignee | ||
Comment 8•13 years ago
|
||
...which is why I filed bug 745744.
We need the patch in this bug for correctness.
Assignee | ||
Updated•13 years ago
|
Component: General → Geolocation
Product: Toolkit → Core
QA Contact: general → geolocation
Comment 9•13 years ago
|
||
Comment on attachment 615329 [details] [diff] [review]
patch
Review of attachment 615329 [details] [diff] [review]:
-----------------------------------------------------------------
fix nsIDOMGeoPositionErrorCallback and nsIDOMGeoPositionCallback in another patch or followup.
Attachment #615329 -
Flags: review?(doug.turner) → review+
Assignee | ||
Comment 10•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•