Closed Bug 752904 Opened 12 years ago Closed 12 years ago

aaQQin (beta) leaves zombie compartments

Categories

(WebExtensions :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eviljeff, Unassigned)

References

()

Details

(Whiteboard: [MemShrink:P3])

aaQQin (beta) leaves zombie compartments for every page visited.  You don't seem to have to activate any of the recommendation features first.

Steps to reproduce:
1) open a new tab and navigate to a site (e.g. bbc.co.uk/news)
2) close tab
3) open about:memory?verbose and press minimize memory button a few times

The site remains.

Repeating the steps seems to produce multiple compartments.

I tested 0.5 but previous versions may also be affected.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P3]
developer chased via info request
developer replied by email saying they are working on it.
Hi Andrew

I am working for above issue mentioned. Have corrected most of the place for zombie issue. While working I came to know about jquery tabs library creating a zombie compartment. Below is my code 

$j(mydiv).find('#targetid').tabs({selected: 2});

Without this line, code doesn't create the zombie compartment.

Have spent quite a long time for this but didn't get a way to rid of this. 
Also I am not using jquery.cookie.js for cookies.

Any help would be highly appreciated

Regards,
aQQin
It's not clear to me how jquery is supposed to work from an extension.

I presume you're loading jquery in your extension's chrome scope?  jquery tabs probably keeps some global pointer to all the tabs, assuming that that global pointer will go away when the page goes away.  But if you've loaded jquery into your extension, rather than into the page, then that global variable stays alive forever...
Hi Andrew/Justin 

I get workaround this with content script. I created a content script that actually create the jquery tabs. Below is my content script code .
==========
addEventListener('DOMContentLoaded', function(aEvent) {
    with(content) {
			var scriptLoader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"].getService(Components.interfaces.mozIJSSubScriptLoader);
			scriptLoader.loadSubScript("chrome://myext/content/js/jquery-1.7.1.js", window);
			if (typeof jQuery != 'undefined' && jQuery != null && jQuery != 'undefined') {
			  scriptLoader.loadSubScript("chrome://myext/content/js/jquery.ui.core.min.js", jQuery);
			  scriptLoader.loadSubScript("chrome://myext/content/js/jquery.ui.widget.min.js", jQuery);
			  scriptLoader.loadSubScript("chrome://myext/content/js/jquery.ui.tabs.min.js", jQuery);
			}
    }
}, true);

// Added message listner
addMessageListener("create_rec_widget", function(message){
	with(content) {
		if (typeof jQuery != 'undefined' && jQuery != null && jQuery != 'undefined') {
			if ( jQuery(content.document).find("#" + message.json.rec_id).length > 0 ) {
				jQuery(content.document).find("#" + message.json.rec_id).find('.aqqin-rwtabs').tabs({selected: 2});
			}
		}
	}
});
=================

I am encountered with a wired issue. 
This content script does work fine if I keep open "about:addons" / "about:compartments" tab in browser. If I close "about:addons"/"about:compartment" tab, script does work. 

I try to debug and it looks like content script is getting loaded but doesn't working. 

I am loading above content script as below.
window.addEventListener("load", function(){
gBrowser.addEventListener('DOMContentLoaded', function (event) {
 window.messageManager.loadFrameScript("chrome://myext/content/js/contentScript.js", false);
},false);
},false);


Am I doing something wrong?

Regards,
aQQin
Sorry Typo :(

If I close "about:addons"/"about:compartment" tab, script does work. 
====================>
If I close "about:addons"/"about:compartment" tab, content script DOESN"T work.
Kris, maybe you can help here?
So... this is part of the reason I hate letting extensions use jQuery and jQuery UI in chrome code. If they need to be used, they should used from a content sandbox.

I wrote a quick script to walk the object tree of the jQuery instance:

let seen = [];
function rec(obj, path) {
    function belch(e) {
        dump(path.join(".") + ": " + e.fileName+":"+e.lineNumber+": " + e + "\n")
    }
    if (~seen.indexOf(obj))
        return;
    seen.push(obj);
    try {
        for each (let prop in Object.getOwnPropertyNames(obj)) {
            try {
                let child = obj[prop]
                try {
                    if (child instanceof Ci.nsIDOMNode || child instanceof Ci.nsIDOMWindow)
                        dump(":: " + path.join('.') + "\n");
                }
                catch (e) { belch(e) }
                rec(child, path.concat(prop));
            }
            catch (e) { belch(e) }
        }
    }
    catch (e) { belch(e) }
}
rec(jQuery, ['jQuery']);

It looks like what's happening is that nodes from the content document that jQuery is interacting with are being stored in jQuery.cache. Fortunately, bug 695480 takes care of this and it's not a problem in Minefield, but it's still one more reason not to use jQuery in chrome code to interact with content documents.

As for your workaround, I'm completely lost as to what you're asking. It may be best to ask on https://forums.mozilla.org/ or irc://irc.mozilla.org/extdev
aQQin, have you been able to find a solution to your problem?
We could not solve the original problem, and as such instead of loading the JS(content script), we wrote our custom css and js to get around the problem.
Jorge/Andrew

This is fixed in the new version(0.6) that we have sent for review.
I couldn't test 0.6 properly due to other problems. We're waiting for a corrected version to be submitted.
Jorge,

The issue with our ssl certificate. For some reason it works fine with Windows and Linux Mozilla, but were giving an error on Mac installation of Mozilla. 

Have fixed it now. Could you please review and let me know if you face any issues.
I can still reproduce the zombie compartment using the testing steps in comment #0.
Are you able to reproduce this issue in your latest update? The steps in comment 0 also reliably reproduce it for me in Firefox 13.
If this isn't fixed soon, we're going to have to downgrade your add-on to preliminary review.
We are working on this. We have resolved most of the cases which were producing zombie. We are working on testing it completely again. 

Also, we noticed that at times we have zombies on Windows built of firefox, but not on the linux built. Is this expected behavior?
(In reply to aQQin from comment #17)
> Also, we noticed that at times we have zombies on Windows built of firefox,
> but not on the linux built. Is this expected behavior?

Do you mean that you see zombie compartments being created even without any add-ons installed?
No, we didn't see the zombies without the add-on installed. However for certain workflow we saw zombies coming only in the windows built of Firefox. They didn't happen on other OS.
We have now fixed these workflows on Windows as well and would be submitting the extension on 19th July.
This has been resolved in the new extension version ( 0.6.1 )
I can no longer reproduce the zombie compartment.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Add-ons → General
Product: Tech Evangelism → WebExtensions
You need to log in before you can comment on or make changes to this bug.