Nils Maier [:nmaier] Reporter
	Description • 13 years ago

STR:
- Install the add-on
- Disable the add-on
- about:memory?verbose + Minimize Memory Usage
-> The add-on compartments are still present

The add-on was built with the 1.5 SDK, so it does not suffer from the recently discovered leak bugs in the SDK itself.

Jeff: Might there be still other leak issues around? Does the SDK team have test-coverage for such leaks by now?

	Jeremy Cutler
	Comment 1 • 13 years ago

To clarify, it is only necessary to install the add-on, and then immediately disable it? No need to visit the target website (tumblr.com)?

If so, this would leave only the options page and main.js as the possible source of the issue.

	Jeff Griffiths (:canuckistani) (:⚡︎)
	Comment 2 • 13 years ago

Hi Nils, 

Thansk for reporting this; I'm cc'ing Irakli and Alex from the SDK team to look into this issue.

For ease of replication / testing, can you please attach an xpi we can use?

Also - what platforms & versions of FF have you tested on?

	Nils Maier [:nmaier] Reporter
	Comment 3 • 13 years ago

This version was is affected

	Nils Maier [:nmaier] Reporter
	Comment 4 • 13 years ago

(In reply to Jeremy Cutler from comment #1)
> To clarify, it is only necessary to install the add-on, and then immediately
> disable it? No need to visit the target website (tumblr.com)?
>
> If so, this would leave only the options page and main.js as the possible
> source of the issue.

You don't need to open the options page. You may observe the zombie compartments already if you start Firefox with missing-e installed but disabled and then enable and disable it (basically slowly double click the corresponding add-on manager button). The options page will not be opened then (only on first run).

(In reply to Jeff Griffiths from comment #2)
> Also - what platforms & versions of FF have you tested on?

Firefox 10 Win32 and Firefox 13a Win64. The latter shows only one compartment, but I guess that's due to sameGroupAs sandboxes?

Seems to me that contrary to the release notes that the fix for bug 724404 did not make it into the 1.5 release?!

	Nils Maier [:nmaier] Reporter
	Comment 5 • 13 years ago

Indeed, bug 724404 is missing from the 1.5 release. I just verified that, and also verified these leaks are gone after:
# git checkout -b release release
# git cherry-pick 6ce857ea134299e5297b75bee2ff5acfc7f77fb2
And then hacking the XPI and including the resulting windows.js

The fix is in master and stabilization only.

Jeremy: I don't think there is anything you can do at the moment and have to wait for the SDK team to put out a release containing the fix.
You may disable the widget, but that would be overkill for this kind of leak. There won't be any leaks during normal operation, just when disabling (user initiated or during updates of your add-on).

SDK team: Do you plan any 1.5.1 that can include the bug 724404 fix? If not, when do you plan to release 1.6?
(Oh, and your git layout kinda confuses me a bit :p)

Also CC'ing Jorge, as this the require("widget") leak still present affects how we should review SDK add-ons, i.e. denying full reviews because of SDK compartment leaks would be inappropriate.

	Andrew Williamson [:eviljeff]
	Comment 6 • 12 years ago

An update was submitted that didn't have a memory leak but failed to work properly (so might not have initialised the memory-leaking bit anyway)

	Jorge Villalobos [:jorgev] (he/him)
	Comment 7 • 12 years ago

The latest update still has problems with jQuery, so we can't be sure the leak has been addressed yet.

	Jorge Villalobos [:jorgev] (he/him)
	Comment 8 • 12 years ago

It turns out that the jQuery problem was on our side and it wasn't a real bug in the add-on. After resolving this, I tested and approved the latest version. The leak seems to be gone.