Closed
Bug 752904
Opened 12 years ago
Closed 12 years ago
aaQQin (beta) leaves zombie compartments
Categories
(WebExtensions :: General, defect)
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.
Updated•12 years ago
|
Whiteboard: [MemShrink]
Updated•12 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P3]
Updated•12 years ago
|
Reporter | ||
Comment 1•12 years ago
|
||
developer chased via info request
Reporter | ||
Comment 2•12 years ago
|
||
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
Comment 4•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
Kris, maybe you can help here?
Comment 8•12 years ago
|
||
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
Comment 9•12 years ago
|
||
aQQin, have you been able to find a solution to your problem?
Comment 10•12 years ago
|
||
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.
Comment 11•12 years ago
|
||
Jorge/Andrew This is fixed in the new version(0.6) that we have sent for review.
Comment 12•12 years ago
|
||
I couldn't test 0.6 properly due to other problems. We're waiting for a corrected version to be submitted.
Comment 13•12 years ago
|
||
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.
Comment 14•12 years ago
|
||
I can still reproduce the zombie compartment using the testing steps in comment #0.
Comment 15•12 years ago
|
||
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.
Comment 16•12 years ago
|
||
If this isn't fixed soon, we're going to have to downgrade your add-on to preliminary review.
Comment 17•12 years ago
|
||
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?
Comment 18•12 years ago
|
||
(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?
Comment 19•12 years ago
|
||
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.
Comment 20•12 years ago
|
||
This has been resolved in the new extension version ( 0.6.1 )
Comment 21•12 years ago
|
||
I can no longer reproduce the zombie compartment.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•5 years ago
|
Component: Add-ons → General
Product: Tech Evangelism → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•