arantius
commented
9 years ago Closed arantius closed 9 years ago
arantius
commented
9 years ago GM_registerMenuCommand().arantius
commented
9 years ago Posted today to greasemonkey-users:
Issue: After updating to Firefox 38.0.5 AND Shockwave Flash 18.0.0.160, I started noticing frequent hangs and crashes particularly when I was viewing video or visiting sites with heavily embedded video content. Today this interfered so much with my ability to work productively I started researching to find solutions.
Technical Details:
Windows XP (sadly) with SP3
FF version aforementioned
Flash version aforementioned
Greasemonkey version 3.2User scripts/GM extensions installed at time of issue:
Turkopticon 3.41.1
HIT Scraper WITH EXPORT
Highlight Unhighlightable Text (CrowdSource)
MTurk HIT DataBase
No other plugins or extensions enabled.Instances of issue:
Various surveys hosted by Qualtrics (many with embedded video, but many others without). Virtually any page with video, Flash and YouTube included, especially with embedded videos. Even general browsing was much slower than normal.Steps taken to resolve:
- Checked for updates to Firefox and Flash (none).
- Disabled all aforementioned GM extensions (issue persisted).
- Disabled Flash along with all aforementioned user scripts (issue persisted).
- Kept GM extensions disabled and selected "Ask to Allow" under Flash options (persisted).
- Changed about:config to block images from sites (persisted).
- Updated Malwarebytes database and ran a threat scan.
- Quarantined 4 PUP.optional.conduittb.gen instances & assumed this would resolve the issue.
- Left all GM extensions and Flash disabled and attempted to browse as normal (persisted). Enabled Flash and browsed as normal (persisted).
- Googled "Firefox slow in 38.0.05" and clicked on a recent Mozillazine thread that indicated Greasemonkey itself might cause significant memory leaks.
- Googled "Greasemonkey memory leak Firefox" and clicked on a recent Reddit post detailing the same issue.
- Finally disabled Greasemonkey and Turkopticon plugins and issue was immediately resolved. No hanging, no crashing, back to working smoothly.\ Enabled Flash and tested on sites with Flash embedded; also went directly to YouTube and watched videos with absolutely no issue.
I don't think it's an extension considering issue persisted when those were disabled. Process of elimination shows the root of the problem is either Greasemonkey itself or the Turkopticon plugin. Evidence from Mozillazine and Reddit indicate similar issues when Turkopticon was not in use. Hoping to get feedback before reinstalling Greasemonkey without Turkopticon in case this is a known and fixable issue.
arantius
commented
9 years ago The email referenced above encouraged me to run a test of my own. Using the normal profile/extensions/tabs/etc. sitting in front of me at the time:
firefox.exe stabilizes. (~30s)It never really stabilized, so measurement noise is me trying to pick an appropriate number without waiting forever. For this test I did nothing besides close and re-launch the Firefox window repeatedly, with "restore tabs" active (and once enable the Greasemonkey add-on, the AOM was the default open tab the whole time).
So that's clearly ~double usage where Greasemonkey being enabled/disabled was the only change. That's no rounding error. Something is definitely going on. Now to isolate variables. Is any (recent?) Greasemonkey release better/worse? Same for Firefox itself? What happens with a simpler profile? Is Flash at all related?
Betsy25
commented
9 years ago I was getting Out of Memory messages multiple times daily when using GM3.x and watching long Flash video's (1hour+) on Firefox nightly v41 Since i switched back to GM2.3 a few weeks ago, I've yet to see my first Out of Memory warning.
EDIT: Userscripts used when on Youtube :
arantius
commented
9 years ago Repeating this morning with Firefox 38.0 on Linux, brand new completely blank profile, nothing installed but Greasemonkey, no saved tabs or anything else. RSS: 149,704; 146,140; 155,956.
That was with GM enabled. Disabled produces ~the same RSS: 143,680; 144,548; 147,060.
All this really tells me is that it's some feature of GM (which is no surprise). Test above was my normal profile, Sync enabled, multiple pinned tabs, ~dozens of extensions and user scripts installed. Something in that giant mess really exacerbated things. This test is a blank profile with nothing enabled/installed, so it's not nearly so bad.
Same test except I do ten navigations to a simple testing page each... no change with GM disabled. Enabled, RSS: 166,392; 159,624; 152,708; 162,340. A subtle but definitely nonzero increase.
Also install testing script and repeat, GM enabled... RSS 162,752; 162,472; 160,844. No real change.
I just imagined another easy test: only one navigation at launch, but to a page which IFRAMEs 100 other pages. I've got GM installed, with above-mentioned test script. Each launch produces RSS: 251,424; 238,564; 231,764; 241,856. GM disabled: 204,996; 199,784; 199,308. Ok, that's a 15-25% change.
Now how about with GM 3.0.1 instead? 248,512; 250,872; 239,984. Still there. Next, GM 2.3.1: 237,108; 236,192; 235,536. Maybe a tiny bit better? I've probably got some measurement noise here because the test script adds content to the (100) document(s) being loaded, which will naturally consume some memory.
Can we isolate that? How about comparing 2.3.1 to 3.0.1, both enabled but also both with no scripts installed? 2.3.1: 213,168; 205,112; 206,352. 3.0.1: 226,760; 209,436; 204,784. No real difference. Whatever is going on, it's related somehow to actual scripts, not to "base" Greasemonkey implementation.
arantius
commented
9 years ago Continuing to try to isolate the source. Detail again: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0. Freshly emptied testing profile. Open page with 100 IFRAMEs in it, preference "show tabs from last time", restart Firefox 3x; observe RSS until it's stable (first time watch -d shows no difference in its value), values: 215156 209356 195568.
Same, install GM 2.3.1 but no scripts yet: 208892 208996 211004. No significant change.
Install GM 3.0.1, repeat: 216308 206088 201940. No significant change.
Install GM 3.2, repeat: 216464 221396 216668. Possibly the tiniest bit worse, but I'm not sure that's significant.
Seems like confirmation that GM on its own is not enough to trigger this. Install five scripts that do nothing (just call dump() once). Repeat with:
GM 3.2: 235088 216976 220484.
GM 3.0.1: 229048 250844 239808.
GM 2.3: 232092 251456 218408.
So I'm operating on the assumption that if something is wrong now, it must have been introduced in the big changes made for 3.0, and e10s compatibility. I see no clear 2.x vs. 3.x differences there, so if it exists (my first observation above sure seems to say it does), this is not enough to trigger it.
arantius
commented
9 years ago GM 3.2, add a single (unused) @grant to each of the five scripts. 246616 212588 220008 234740.
arantius
commented
9 years ago Same, but actually use GM_registerMenuCommand()... 242756 248312 233332 223048. Still not significant.
Ok, original test again. Normal day-to-day profile with tons of stuff installed. RSS just after launch (back into the realm of never-really-stabilizes, doing my best to pick representative numbers): 1896672 1887456 1893060. Repeat, with GM (3.2beta4) disabled: 823748 806664 833100.
So, still: the heavyweight things installed/lunched consume ~800M as compared to the ~200M of a mostly empty profile, but just enabling GM more than doubles that.
Next step: reproduce this data but divorce it from my regular profile, and its Sync account. So more invasive tests are safe. First one: move the gm_scripts directory away, so that everything except the installed scripts are still active.
RSS: 813848 816548 836240.
Scripts gone, ~double memory consumption gone. There's still a huge surface left, but this seems like pretty good progress.
arantius
commented
9 years ago Same, but actually use GM_registerMenuCommand()... 242756 248312 233332 223048. Still not significant.
Ok, original test again. Normal day-to-day profile with tons of stuff installed. RSS just after launch (back into the realm of never-really-stabilizes, doing my best to pick representative numbers): 1896672 1887456 1893060. Repeat, with GM (3.2beta4) disabled: 823748 806664 833100.
So, still: the heavyweight things installed/lunched consume ~800M as compared to the ~200M of a mostly empty profile, but just enabling GM more than doubles that.
Next step: reproduce this data but divorce it from my regular profile, and its Sync account. So more invasive tests are safe. First one: move the gm_scripts directory away, so that everything except the installed scripts are still active.
RSS: 813848 816548 836240.
Scripts gone, ~double memory consumption gone. There's still a huge surface left, but this seems like pretty good progress. Restore scripts. Mark them all disabled. Repeat test, RSS: 813136 827772 806672.
Ok. It's definitely (though this is still no big surprise) something about running the scripts that causes this. So begins the involved process of figuring out any further detail than that. Is any one/few (of my 44) script(s) the problem? Does each script contribute just a little bit?
With (the first, alphabetically) half of my scripts installed, RSS after launch is 869904 870660 866696. Possibly a ~7% increase, which could easily be explained by the actual/intended actions of 22 scripts. Enable half of the remaining (11 more), RSS: 845500 881508 860716. No appreciable change. Enable five more... 862772 851944, still no change. Enable all that remain, except the one script which happens to alphabetize near the end, and which I suspect (especially at this point). One of the few I run that I didn't write. RSS: 860476 863532, yep still all the same basic range.
So is it that one last script? Test yet again, no change from the last besides enabling it ... RSS: 1910792 1935812 . Well! There it is. With that knowledge let's see if I can produce a simpler set of steps to reproduce ...
It's not quite so clear as double memory usage, but this is a good ~30% increase. I don't think YTCenter is necessarily at fault, it just happens to be a good stress test: over 26 thousand lines, making use of a wide variety of APIs/features available. That's also sadly the reason that it's an awful part of any steps to reproduce. How much memory does it take to just parse/execute 26k lines of javascript? How much of the observed extra ~70MB does that account for? How much by all the DOM manipulation being done?
To really confirm, downgrade to GM 2.3.1 and repeat. Observed RSS: 256740 257408 247572. No, that's still elevated (probably for legitimate reasons; memory to hold those 26k lines of JS, all the DOM manipulations the script does, etc.).
Are claims above that recent Firefoxen exacerbate the issue correct? I've got a copy of 35.0.1 handy, which produces: 239804 224608 230916. Pretty much the same, possibly a hair better.
Well that's a giant pile of data, but I'm still unsure what to make of it.
arantius
commented
9 years ago Stress test. Create a file with 36 YouTube embeds. Launch Firefox to about:blank only (155728).
Open pile of youtube (309616). Close that tab (208528). Open pile of youtube (309688). Close that tab (208852). Open pile of youtube (314592). Close that tab (213684).
No leak. All memory reasonably consumed by embedding 36 videos is released. Enable YTCenter.
Open pile of youtube (1234888). Close that tab (251844). Open pile of youtube (994864). Close that tab (249880). Open pile of youtube (981448). Close that tab (269672). Open pile of youtube (1012536). Close that tab (251776).
Increased memory consumption, but no leak. Closing the tab always puts us back down to right around the same amount of memory used.
Oh! I was about to go do this with 2.3 to see if that made a difference -- I was on GM 2.3 the whole time! On 3.2 everything looks the same. Open/close that tab fluctuates ~1000/~225 MB used.
Or: I still haven't located the cause.
arantius
commented
9 years ago https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/reviews/713090/
3,2 memory leaks with this script for me: https://greasyfork.org/en/scripts/404-mouseover-popup-image-viewer
arantius
commented
9 years ago I've been browsing normally for a while. Windows shows ~1.5GB memory consumed by Firefox. about:memory shows "1,508.84 MB (100.0%) -- explicit" which agrees. I still generally don't know how to read about:memory well, but some high level things:
122.81 MB (08.14%) -- string(length=2925786, copies=22, "/**/n The MIT License (MIT)/n/n Copyright /xA9 2015 Jeppe Rune Mortensen .... That's 22 copies of YouTube center('s source code) in memory. (!!) ├────509.43 MB (33.76%) -- window-objects
│ ├──380.15 MB (25.20%) -- top(none)
│ │ ├──378.86 MB (25.11%) -- ghost
│ │ │ ├──169.85 MB (11.26%) ++ window(https://www.youtube.com/watch?v=rmQPUZQ4nPA)
│ │ │ ├───63.69 MB (04.22%) ++ window(https://www.youtube.com/playlist?list=WL)
│ │ │ ├───34.74 MB (02.30%) ++ (6 tiny)
│ │ │ ├───34.03 MB (02.26%) ++ window(https://www.youtube.com/watch?v=TWcL0OF_eQI&list=WL&index=2)
│ │ │ ├───30.21 MB (02.00%) ++ window(
│ │ │ ├───29.82 MB (01.98%) ++ window(https://www.youtube.com/watch?v=D54QVBCBhno&feature=youtu.be)
│ │ │ └───16.52 MB (01.10%) ++ window(https://www.youtube.com/watch?v=L4AJmvzImbM&index=3&list=WL)
│ │ └────1.29 MB (00.09%) ++ detachedI don't have any YouTube tabs open right now, besides the watch later page. Either way it's just one of those six YT pages, with the others showing ~282MB consumed there. So those sure seem to be leaked. Unfortunately "just use the internet for several days" is not the sort of steps-to-reproduce that leads to an easy fix. Also two of those "6 tiny" entries are other YT pages which also aren't open, another ~30MB.
So again I can only read this approximately, but most of the difference from a "normal" (several hundred MB) Firefox to now seems to be explained by leaked-looking YouTube pages... This lines up with other people's references to playing videos?
For now I'm probably going to disable YT Center for a while (ick! I'm so used to it) and see if I notice a difference in the memory consumption trend of my normal browsing habits.
arantius
commented
9 years ago https://www.reddit.com/r/firefox/comments/3atub9/ including https://www.reddit.com/r/firefox/comments/3atub9/firefoxx/csgf0v9 "Not using Youtube Center. Only using uBlock Origins and NoScript."
grace6942
commented
9 years ago Hello,
I am the person who posted the email referenced above which prompted you to "run a test of [your] own".
_I AM NOT NOW NOR HAVE I EVER USED YOUTUBE CENTER. EVER._
Is that clear? I listed all of the extensions, plugins and add-ons I use in my original email and for some reason you are concerned about Youtube Center? Man, the problem is GREASEMONKEY 3.2 + Firefox 38.0.5. PERIOD. I'm not even a techie and I can see that!!
Keep fiddling around with it if you want to, but at the very least tell us what we can do to work around it in the meantime. Some of us depend on scripts that are dependent on Greasemonkey FOR A LIVING.
Thanks.
TarkusLV
commented
9 years ago Keep fiddling around with it if you want to, but at the very least tell us what we can do to work around it in the meantime. Some of us depend on scripts that are dependent on Greasemonkey FOR A LIVING.
The workaround (for now) is to install Greasemonkey 2.3.1 and disable automatic updates for that extension. The problem being discussed here isn't present in that version, and it's doubtful you'll lose any functionality.
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/2.3.1-signed
grace6942
commented
9 years ago Thank you, TarkusLV!!!!
yarrmateys
commented
9 years ago the problem happens even without youtube center, it's possible other scripts get stuck this way too. i wonder if this is responsible for the heavy cpu use firefox eventually reaches, making it extremely laggy and unresponsive until it's restarted.
if it keeps duplicating scripts in memory like this, is it possible that all those extra script copies are still running, multiplying and wasting cpu cycles on doing practically nothing?
arantius
commented
9 years ago Quoting my own self:
I don't think YTCenter is necessarily at fault, it just happens to be a good stress test: over 26 thousand lines, making use of a wide variety of APIs/features available.
Not to mention all the things linked above where other people do cite it as the cause of similar issues. (That said despite all my efforts, I haven't been able to reproduce any leak/crash. Memory leaks are very hard to diagnose even when they are known to occur.)
yarrmateys
commented
9 years ago yeah, and if greasemonkey does keep scripts in memory and somehow allows them to both function and maybe even duplicate themselves (or at most, not unload after page's closed or refreshed/auto refreshed, but instead creating another script), then it doesn't matter if it's yt center or anything else. yt center just makes the problem noticable because of what you said about stress testing.
it is an extensive script, so having multiple copies of it running for no reason could be contributing to the overall sluggish performance many people, myself included feel when they use greasemonkey 3.x
for the record, rolling back to 2.3.1 removes the issue, so whatever happens may be related to whatever was added to gm3+, like for example multi process/electrolysis support.
grace6942
commented
9 years ago In case this helps:
I reverted to GM 2.3.1 early this morning and instead of things getting better, they got significantly worse. My computer was rendered virtually unresponsive almost constantly. I finally checked to see if Flash was still up to date and saw that an update was available (18.0.0.194). I installed that and hoped things would improve, but the memory leaks continued unchecked. Finally out of sheer frustration I checked the GM page and saw that an update was issued today along with the Flash update. Installed the GM update (3.2?) and now everything is working perfectly. No crashes, no hangs, no memory leaks. PERFECT. I really hope it stays this way and thank you so, so, so much to everyone involved in whatever it is that made things right again!!! :) :) :)
yarrmateys
commented
9 years ago greasemonkey 3.2 is from may though, it wasn't released today.
i don't even have flash enabled in my firefox for the record. disabled it a while ago, so now it only activates when i allow it to, which i almost never do.
grace6942
commented
9 years ago Is it maybe then something with Flash that wasn't working with 3.2 until today's Flash update? Maybe?
Thanks and take care.
Jessica
On Tue, Jun 30, 2015 at 11:20 PM, yarrmateys notifications@github.com wrote:
greasemonkey 3.2 is from may though, it wasn't released today.
— Reply to this email directly or view it on GitHub https://github.com/greasemonkey/greasemonkey/issues/2200#issuecomment-117423847 .
TarkusLV
commented
9 years ago Has nothing to do with Flash, since I don't even have Flash installed here.
grace6942
commented
9 years ago Well, all I can say is what I've already said and hope it helps the developers in some way. Again, with the update to Flash 18.0.0.194 and using GM 3.2 everything is still working perfectly. No leaks, no crashes, everything is beautiful.
janekptacijarabaci
commented
9 years ago See also http://forums.mozillazine.org/viewtopic.php?p=14214425 (youtube, embeds HTML5...)
I don't have time to test it now...
TimidScript
commented
9 years ago Since upgrading to FireFox 39 my memory consumption is about 4 times less (so far).
arantius
commented
9 years ago If:
At let me know if things get better, worse, or no change. Somehow my steps to reproduce ghost windows from this morning don't work anymore, but I've done two things that may help the situation. Confirmation either way would be real nice.
amccreight
commented
9 years ago Hi, I work on Firefox. Could you link to the changesets that you think helped this issue? I'd like to understand what the issue was on the Greasemonkey side. I'm also working on a fix on the Firefox side that should mitigate these page leaks via sandboxes ( https://bugzilla.mozilla.org/show_bug.cgi?id=1174950 ).
amccreight
commented
9 years ago Also, please file bugs and cc me if you find bugs like these. Addons shouldn't be able to cause severe page leaks (ghost windows) like this. If they can, that's a bug in Firefox.
arantius
commented
9 years ago Well I have to start by saying that we have one report for and one against this actually helping, but we're talking about storing references to content browsers (specifically, the message .target, just so that we can post another message back later), and I:
1) Tried to use weak references (8360d3b1db0ffff6641f51a77c3dad2c6704f11a) and 2) Tried to sweep out stale references (4966b74541eb206921c7a7391dcc7f899281ff86). (These commits have only been pushed to a branch in my account, so far.)
This was mostly stabbing in the dark at the GM_registerMenuCommand feature, because it seems (#2067) to be the common/real/root cause. This feature allows a script running in a sandbox to register a little bit of UI in chrome, to trigger a callback. After e10s (support was added), we're forced to A) post a message from content to parent process, then B) store data about the registered command, critically including a reference to the content scope it's related to, so that the parent/chrome can C) post a message back to content to get the callback to run. It's chrome, not sandbox, code doing this, as it has to interact with the chrome UI to provide the feature.
We're supposed to be clearing these references when the related content disappears, but I'll just say that and avoid a rant about how hard it was to support e10s. That section is probably not behaving the way it used to before message managers and multi-process was a thing (that we tried to be compatible with). Maybe it's just another one of the multitude of kinds of message sources and destinations that isn't getting through as expected. Maybe something else.
I've had quite a lot of trouble narrowing the true root cause down. Steps to reproduce suddenly stop doing what they used to, even when "successful" ones are found. The reference to doing "minimize memory" twice in the bug you linked is .. interesting.
amccreight
commented
9 years ago This bug also had a good set of steps to reproduce: https://bugzilla.mozilla.org/show_bug.cgi?id=1181122
Here is the interesting part of the chain of ownership keeping the document alive:
0x1227a8e50 [JS Object (XPCWrappedNative_NoHelper)] --[js::GetObjectPrivate(obj)]--> 0x121b5b9e0 [XPCWrappedNative] --[mIdentity]--> 0x12256eee0 [nsFrameLoader] --[mChildMessageManager]--> 0x1225b5040 [DOMEventTargetHelper ] --[mAnonymousGlobalScopes[i]]--> 0x121d7f340 [JS Object (NonSyntacticVariablesObject)] --[gScriptRunners]--> 0x121a55f20 [JS Object (Object)] --[objectElements[45]]--> 0x12bf7a100 [JS Object (Object)] --[menuCommands]--> 0x12ec09760 [JS Object (Array)] --[objectElements[0]]--> 0x111dbece0 [JS Object (Proxy)] --[private]--> 0x12c148640 [JS Object (Object)] --[commandFunc]--> 0x111dbeca0 [JS Object (Proxy)] --[private]--> 0x1299c8b40 [JS Object (Function - $._main/<)] --[fun_environment]--> 0x129344900 [JS Object (Call)] --[callee_slot]--> 0x12c13f400 [JS Object (Function - $._main)] --[fun_environment]--> 0x1214ca100 [JS Object (Call)] --[document]--> 0x12144fa60 [JS Object (Proxy)] --[private]--> 0x121dd5060 [JS Object (HTMLDocument)]
There's some gScriptRunners thing, which has a menuCommands array, and then there's some commandFunc, which maybe is a function in the sandbox. Then that ends up entraining the content document. The "JS Object (Proxy)" things are when we transition from an object with one global to another. So the last one is where we go from the sandbox to content. Maybe the one before it is where we go from a system thing into the sandbox.
If you have a sandbox associated with a page, and you know the page is going away, then you can call Cu.nukeSandbox() on the sandbox. This should ensure that chrome script isn't keeping alive the sandbox. I think that's where Greasemonkey is going awry, though it could be a bug in some addon SDK kind of thing you are calling, too.
arantius
commented
9 years ago We never store a reference to the sandbox; it's created local to a function and never passed out of it.
The things you're describing:
If you have a sandbox associated with a page, and you know the page is going away
That's never been necessary in the past. My musing above was just figuring that if this workaround (not fix, really) helps, it's probably because our existing clean-up code isn't working as intended. Hopefully the description above shows that the (very indirect) reference to the content window is completely intentional and necessary, for the feature we've got to work as designed.
If chrome/the parent could send a sync message to content/the child (and get back a response) (i.e. query the registered commands when the menu is popping up), this would probably be OK, we wouldn't have to store any references, or perhaps would only need to for the duration that the menu is open.
amccreight
commented
9 years ago Hmm, ok. Also, in bug 1181122 I bisected down to a specific Firefox changeset that caused Greasemonkey to start leaking, but I don't know anything about the code that changed. I'm hoping the developer who landed that patch will be able to comment.
arantius
commented
9 years ago I tested the hypothesis discussed above. I added some logging:
diff --git a/content/framescript.js b/content/framescript.js
index bfaeac1..bf9f1b2 100644
--- a/content/framescript.js
+++ b/content/framescript.js
@@ -194,11 +194,13 @@ ContentObserver.prototype.pagehide = function(aEvent) {
if (!gScriptRunners[windowId].menuCommands.length) return;
if (aEvent.persisted) {
+ dump('SEND greasemonkey:toggle-menu-commands (frozen=true; window='+windowId+')\n');
sendAsyncMessage('greasemonkey:toggle-menu-commands', {
frozen: true,
windowId: windowId
});
} else {
+ dump('SEND greasemonkey:clear-menu-commands (window='+windowId+')\n');
sendAsyncMessage('greasemonkey:clear-menu-commands', {
windowId: windowId
});
@@ -214,6 +216,7 @@ ContentObserver.prototype.pageshow = function(aEvent) {
if (!gScriptRunners[windowId].menuCommands.length) return;
+ dump('SEND greasemonkey:toggle-menu-commands (frozen=false; window='+windowId+')\n');
sendAsyncMessage('greasemonkey:toggle-menu-commands', {
frozen: false,
windowId: windowId
diff --git a/content/menucommander.js b/content/menucommander.js
index 16df26b..5a4b278 100644
--- a/content/menucommander.js
+++ b/content/menucommander.js
@@ -55,6 +55,7 @@ GM_MenuCommander.menuCommandRegistered = function(aMessage) {
GM_MenuCommander.clearMenuCommands = function(aMessage) {
var windowId = aMessage.data.windowId;
+ dump('RECV greasemonkey:clear-menu-commands (window='+windowId+')\n');
if (!windowId) return;
delete GM_MenuCommander.menuCommands[windowId];
@@ -63,6 +64,7 @@ GM_MenuCommander.clearMenuCommands = function(aMessage) {
GM_MenuCommander.toggleMenuCommands = function(aMessage) {
var frozen = aMessage.data.frozen;
var windowId = aMessage.data.windowId;
+ dump('RECV greasemonkey:toggle-menu-commands (frozen='+frozen+'; window='+windowId+')\n');
GM_MenuCommander.withAllMenuCommandsForWindowId(windowId, function(index, command) {
command.frozen = frozen;Just showing when the relevant messages are posted/received. When I open a new tab and then close it, I get:
SEND greasemonkey:toggle-menu-commands (frozen=false; window=2147483672) RECV greasemonkey:toggle-menu-commands (frozen=false; window=2147483672) SEND greasemonkey:clear-menu-commands (window=2147483672)
My listeners are receiving one class of message, but not the other. Both are dispatched the same way (frame script just calls the global sendAsyncMessage()), both listeners are set up the same way (messageManager.addMessageListener() twice on the same object). One comes through, the other doesn't. Why? Perhaps the change that you bisected to is actually the reason this particular message isn't passed through?
I did some more testing and it turns out that in the "frozen=true" case, our pagehide listener isn't even getting called consistently:
Firefox version: 38: not called 39: not called 40: called 42, e10s on: called 42, e10s off: called
This is (supposed to be) how we clear out our (intentionally) cached content window references. But there's currently no situation in which it's (completely) working. When the pagehide event listener is called, the message it posts is never received on the other end.
arantius
commented
9 years ago I'm going to close this issue in favor of #2067 -- after working on both for a while, I'm pretty sure it's the menu commands at the root of it, so fixing that one should address this one as well. Please comment there if you have more information, or reopen this issue only if you can provide evidence of a problem with something specific that is not GM_registerMenuCommand().
Betsy25
commented
9 years ago Not to spoil the atmosphere, but since I finally updated GM 2.3.1 to the latest official one (now 3.3) which supposedly should have fixed some memory leaks, I have once again gone troughs some weeks with 10-15 system alerts a day, stating that the free system memory is dangerously low, looking in task manager it was indeed Firefox consuming 98-99% of that. (whenever there are tabs open on urls where GM is running.)
I have reverted back to v2.3.1 since 2 weeks, and I'm still waiting for the first low memory system alert.....
Windows 7 x64 Firefox 32bit Nightly v43
Betsy25
commented
9 years ago Well, just forget about the above, the problem is present with GM 2.3.1 also. I guess it's just the horrible html5 implication of Firefox.
Entoarox
commented
7 years ago I have a custom script that does not use GM_registerMenuCommand, this is the only script even installed, let alone used... and yet the firefox issues experienced are identical to those of others reporting here, I believe this issue should be re-opened, as I feel that the issue reported has not actually been solved and is not linked directly to the GM_registerMenuCommand issue.
General tracking issue to gather data about and diagnose any unusual memory consumption caused by Greasemonkey.