Talk:AjaxRC/Archive 1

Options
Tried it myself, but could "Automatically refresh" and "Enable auto-refreshing page loads" be changeable too? Tried it myself, didn't work :P. Mark ( talk ) 15:13, June 22, 2010 (UTC)
 * Added the function.  Manyman  (Talk)  21:56, June 23, 2010 (UTC)
 * And fixed, should now allow options as laid out here. Grunny  ( talk ) 02:12, June 24, 2010 (UTC)
 * Once again, thanks a lot :)! Does it also work with AjaxRC/i18n.code.js? Mark  ( talk ) 16:26, June 24, 2010 (UTC)
 * Don't use i18n.code.js, it's really old code. -- 21:07, June 24, 2010 (UTC)
 * Added to i18n.code.js until this one supports all languages. Grunny  ( talk ) 23:33, June 24, 2010 (UTC)
 * And now have added support for all languages for this one, so you can use this one now, Tedjuh :). Grunny  ( talk ) 23:40, June 24, 2010 (UTC)
 * Yay :). Mark  ( talk ) 17:28, June 25, 2010 (UTC)

Broken
Hello,

there was an update on Wikia today. Now this Script doesn't work anymore. There must be a problem with the loadPageData function, but I'm not able to fix it. So if there is anyone who is able to fix it, please do so.

Also the ajaxRefresh and the incator can't be changed. So may be this can be changed also.

Greetings, TOBBE 14:42, April 27, 2011 (UTC)
 * I think I see what needs updating, but I'm not gonna touch it if I dont have to. I'll ping some JS gurus to take a look when they get on line later. --Uberfuzzy 20:14, April 27, 2011 (UTC)
 * It should be working again now. Cheers, Grunny  ( talk ) 06:54, April 28, 2011 (UTC)
 * That's all well and good, but most people don't use the import. Most instances I see are copy and pasted. The JSON error isn't just with this script, either - most Ajax-related things are turning up bad queries, or unintended JSON strings. The "customize" button for MyTools is returning bad JSON. In fact, I've had entire pages try to load as JSON - this is something that needs to ultimately be fixed on the Wikia end. ~ Monchoman45 ( Talk  |  Contribs  |  Central ) 14:51, April 4, 2011 (UTC)
 * Wikia's fixed the problem on their end, but now there's another problem - the new version of the script won't change the page. It'll refresh, but the page doesn't change, regardless of whether or not a new edit has been made. In testing, I found that the old version works fine. Revert? ~ Monchoman45 ( Talk  |  Contribs  |  Central ) 21:05, April 4, 2011 (UTC)
 * Done. Grunny  ( talk ) 00:08, April 29, 2011 (UTC)

Unable to import
Hello! I'm trying to import the script to w:c:masseffect.answers:MediaWiki:Common.js, but it doesn't seem to work. Upon publishing the page, nothing is added below the import script (importScriptPage('AjaxRC/code.js', 'dev');), and Can you please clarify how it's supposed to work? Or does it require specific wiki extension, or something? Mitranim 06:42, July 23, 2011 (UTC)

Please nevermind. It found that it indeed works, if I import it without setting any additional variables. It doesn't add any additional code to the page, but the auto-refresh box appears on certain pages. I'll try and see what causes the import with additional options to fail. Mitranim 06:55, July 23, 2011 (UTC)


 * Hi. You have a typo in your ajaxPages variable which is causing everything after it to break. Here you need an extra " after the Wikiactivity: . Hope that helps. Cheers,  grunny  :&#126;$ 07:02, July 23, 2011 (UTC)


 * Huh... Silly me. >_< Thanks for the help, and for the quick answer! Mitranim 07:07, July 23, 2011 (UTC)

AdminDashboard
Can someone change the position of the refresh throbber when RC is viewed through AdminDashboard? It is appearing before the header, meaning elements are physically moving for it to appear.
 * That's because of CSS loaded on the dashboard that floats images within that header to the left. I have removed the float on the throbber so it won't do that anymore. Cheers, grunny  :&#126;$ 15:02, August 6, 2011 (UTC)

Changing the throbber
Can someone tell me why the code on the following js page isn't changing the throbber? The code is definitely loading. Common.js


 * Well, no one has replied this u.u, but if somepony wants change the throbber (like me) this was the problem... --ShutterBat (talk) 05:13, January 5, 2014 (UTC)

Security problem
It's a bad idea to use importScriptPage("AjaxRC/code.js", "dev"). Can't anyone edit that page and run arbitrary JavaScript on all pages that use the code? FB100Z &bull; talk &bull; contribs 21:07, January 1, 2012 (UTC)


 * Interesting point. Perhaps, at a minimum, code pages should be semi-protected? Thanks! — Spike Toronto  02:13, January 2, 2012 (UTC)


 * All code pages should be fully protected. Otherwise, any logged-in user can mess with the JavaScript, creating a potential to cause damage to all wikis using the code. FB100Z &bull; talk &bull; contribs 02:16, January 2, 2012 (UTC)


 * That’s not in keeping with the wiki ethos, though. Of course, changes should be discussed on the relevant talkpages, but editing code pages should not be restricted to dev wiki admins only. Moreover, there is only one sysop on this wiki, who has not edited it in three years. Thus, all updates/fixes/etc. have been made by non-sysops (especially Grunny, Monchoman, etc.). Therefore, full protection would be unworkable. I cannot recall any such event as you hypothesize actually having happened. Also, most troublemakers would do so anonymously or with brand-new accounts set up for the purpose: Semi-protection would prevent that. Thanks! — Spike Toronto  02:31, January 2, 2012 (UTC)


 * I completely understand your point, but it's too dangerous to risk the well-being of everyone's browser and Wikia account (primary targets for these attacks) to keep with the wiki philosophy. However, there's a possible solution to this problem:
 * Fully protect all the current code pages, since they're being hardlinked from scripts in many other wikis and are strongly vulnerable to attack.
 * Create new freely editable code pages that aren't hardlinked from other wikis.
 * Every so often, an administrator checks the secondary pages, makes sure they're safe, and copies them to the primary ones.
 * This model could work, although it would be a lot of tedious work for our inactive administrator ;) In the meantime, I would advise all wikis to avoid importing directly from dev.wikia.com; copy-pasting the code into a local script in the MediaWiki: namespace would be much, much safer. FB100Z &bull; talk &bull; contribs 01:24, January 3, 2012 (UTC)


 * I've fully protected the AjaxRC code page since it is a highly-used import, and as I'm the only one who edits it regularly, I figure it can't hurt and requests for changes can still go through me. If you have specific (high-use and stable) code pages you would like protected, just ask :). It might be a better idea to protect high-use pages and give trusted users (trusted in that they can code and aren't going to go nuts) sysop rights as needed as well. Cheers, grunny  :&#126;$ 16:36, January 3, 2012 (UTC)


 * Thanks Grunny! — Spike Toronto  09:43, January 4, 2012 (UTC)


 * Thanks heaps :) Maybe we could create a user group that allows editing of code files. FB100Z &bull; talk &bull; contribs 00:50, January 5, 2012 (UTC)


 * Brilliant idea! And Grunny is just the man to do it. :) — Spike Toronto  23:10, January 5, 2012 (UTC)

(Reset Indent) That would be way too laborious for anyone who wants to post code here, what with going to an rfr, waiting for it to passed and whatnot. Instead why don't you use Pending Changes? Staff and Helpers do visit here quite frequently and they could mark an edit as fine. -- Kangaroopowah ( Talk ) 22:56, January 7, 2012 (UTC)


 * Not a bad idea either. Although I do not think that FB100Z was suggesting a new user group that would require something as onerous as an RfP. I think he was suggesting something somewhere between being an autoconfirmed user and an admin. Something like how one acquires rollback over at Wikipedia: one asks, and the person asked reviews your work, and decides yes or no. — Spike Toronto  01:00, January 8, 2012 (UTC)


 * A brilliant idea, sir. Why didn't I think of that? FB100Z &bull; talk &bull; contribs 20:27, January 8, 2012 (UTC)

I'd like some explanation
Hi anyone who may be reading this. I want to ask a couple of things regarding the script and I'd appreciate a reply.

First of all, the cookie. It's needed in order for the script to remember whether the user has the auto refresh checked or not, am I understanding this correctly? If not what does it store?

Secondly something that is bugging me since yesterday. I want to add the Special:WikiActivity page in the pages that can be auto-refreshed but I also want to use the script locally instead of importing it, so I am not adding var ajaxPages = ["Special:WikiActivity"];, as the instructions suggest (as these instructions are for importing the script). What I have tested and failed instead is to add a second element to the default array of the script, like this if ( !window.ajaxPages ) { var ajaxPages = new Array("Special:RecentChanges","Special:WikiActivity"); } or like this if ( !window.ajaxPages ) { var ajaxPages = ["Special:RecentChanges","Special:WikiActivity"]; }.

As I said, this way is not working and I honestly cannot understand why? What am I overlooking? Regards -- Noemo n  * talk * 01:06, March 11, 2012 (UTC)


 * Hi, yep, that's right about the cookie, it just stores on or off for whether or not the auto-refresh is checked. Setting  should work fine. Can you link me to where it is not working, and also let me know what browser you are using? Cheers,  grunny  :&#126;$ 14:07, March 11, 2012 (UTC)

Conflicting with Other Scripts
Hello. This script seems to conflict with:

It changes the IP back to "A Wikia contributor" after the first refresh, any idea why? Thanks! 03:48, April 10, 2012 (UTC)
 * That's because by default, no scripts in the part of the page are run after the initial refresh. This can be easily remedied through ajaxcallagain. Basic doc for it is on AjaxRC but you can ask Moncho if you still need help as he wrote that part of this script. Best, -- Kangaroopowah  ( Talk ) 05:33, April 10, 2012 (UTC)

Enable Ajax refresh by defaut
Is there a way of making it so the refresh is enabled by default. I'm using it globally, and it seems pointless having to tick the box on every wiki I visit.

I also agree with Eladkse, I think it should be active by default and if someone doesn't want, he has to just untick the option. Another suggestion: can an option be created to active it on namespaces? I think's it's quite useful for forum or blog for example. 22:29, May 14, 2012 (UTC)


 * I wouldn't use it for blogs or message walls Leviathan. It clears the comment boxes!

Wiki-Activity Module
Can you also add the function to the Wiki-Activity Module at the right-column of the page please? Just let it be hidden in there -- Sam Wang (talk) 09:42, May 26, 2012 (UTC)

ShowHide conflict
If I add a collapsible table in Last Changes text-intro, the AjaxRC will expand it automatically. Is it a unavoidable conflict? 13:41, June 14, 2012 (UTC)

Now it apparently create a conflicts with MW Version 1.19, as you can see (everything is expanded). 16:01, July 5, 2012 (UTC)


 * Apparently a fix for this can be found here.  23:05, July 5, 2012 (UTC)


 * Hi, this has been fixed now. Let me knw if there are any more problems. Cheers, grunny  :&#126;$ 23:13, August 10, 2012 (UTC)

Code Lock
It seems that the code is locked and so can be improved or changed. Maybe we can add an V2 or try to contact the staff. It seems the old admins locked them when they created it. --Jens Ingels (talk) 18:57, August 10, 2012 (UTC)


 * Hi. This code is locked for a reason. It is used widely by many, many users so changes to it need to be checked before they are saved. As such, let me know if there is something specifically you want to change about the code and I can check your change and apply it if appropriate. Cheers, grunny  :&#126;$ 23:10, August 10, 2012 (UTC)

Well, some lay-out changes could make the script more practical to use. Something like this for example (photoshop examples):

Image version example:



Image version with text example:



Ofcource with use of a Throbber --Jens Ingels (talk) 00:07, August 11, 2012 (UTC)

Broken in 1.16
The script is currently broken in MW1.16 (and the page is locked). Not all Wikis have been converted yet so could you please add a conditional to handle both until the upgrade is completed? I suppose I can hack around this by explicitly invoking version [ 5602] (when it still worked) but I'd have to rewrite  to support a version parameter in order to do that. Lunarity 04:21, August 11, 2012 (UTC)


 * The built-in  function already supports this (note that   has been superceded by   in MW 1.17.   accepts full urls with parameters: mw:Manual:Parameters_to_index.php


 * Here is an example of how you would use it:

— Mathmagician (message wall)


 * I actually started rewriting  as soon as I posted this (when it occurred to me):


 * It's more flexible this way since I can easily apply the same fix to any other script with a similar problem, it's also backward compatible and fixes a couple of bugs in Wikia's version. I suppose I can improve it by polyfilling mw.loader and using that instead but I'm pretty sure other stuff is going to break after the upgrade anyway so I'll do it then. Lunarity 06:01, August 11, 2012 (UTC)

Problems to Namespace
This script is somehow interfering with the Namespace choosing. It disables the drop down list completely. Can this be fixed? 05:48, August 20, 2012 (UTC)

Doesn't show up
It doesn't seem to show up in, but shows up in. Here's the code:

— SW8573 (Message Wall) 09:58, August 29, 2012 (UTC)


 * "Special:WikiActivity" isn't in the list of pages you posted. It will only show up on pages that are in the list. Lunarity 10:42, August 29, 2012 (UTC)


 * Oh whoops. Silly me. I thought I put it there...must have overlooked it. Thanks — SW8573 (Message Wall) 12:38, August 31, 2012 (UTC)

Mainspace namespace
I'm not sure if this is a known bug given how long this has been happening, but the script doesn't work properly with the AjaxRC when filtering only the Mainspace namespace as it keeps showing everything. I tried with a different account without the AjaxRC script, and the filter works as intended. ··· d·day! 20:14, September 12, 2012 (UTC)

Problem with "see more recent activity".
When I click on "see more recent activity" with the AutoRefresh activated, It doesn't show more Recent activity and I'm sended to the top of the page. Any solution?

EN6


 * I know exactly what you're talking about, it's that link at the bottom of Special:WikiActivity. It has a dynamically-added onclick handler that's supposed to reveal more content, but when AjaxRC refreshes the page the entire page content (including the link) is replaced and the onclick handler is lost. No clue how to fix the problem, but that's what it is. [If someone reading this happens to know where in Wikia's github codebase the implementation and/or documentation for the Special:WikiActivity page is, please post the link here. I wasn't able to find it.]


 * AjaxRC/beta.js should fix this, but Grunny still hasn't pushed it to /code.js. -- Kangaroopowah  ( Talk ) 03:09, April 11, 2013 (UTC)


 * Tested and confirmed that AjaxRC/beta.js fixes this bug. I wouldn't have guessed all you had to do is call  &mdash; makes it look too easy :). Hopefully Grunny pushes that fix soon.


 * The credit for that fix goes to Lunarity. :) -- Kangaroopowah  ( Talk ) 01:55, April 13, 2013 (UTC)

Function Call Again
So I set the wikiSiteMeter function to be called again, and some errors started to happen with that function. Usually the sitemeter only appears once next to the Wikia Entertainment logo at the bottom left, but after each auto refresh a row of sitemeter started to appear.  Babar Suhail    20:20, April 18, 2013 (UTC)


 * (my note below also covers this, it's the same problem)

RevealAnonIP incompatible with latest update?
RevealAnonIP seems to have stopped working since the update to AjaxRC on April 18th. I've also had no luck with calling the function again via ajaxCallAgain. Any ideas?

~ Aelita 19:56, April 20, 2013 (UTC)


 * I recently imported RevealAnonIP to my wiki and it is working fine with the new AjaxRC update. I am also have problems with the function calling.  Babar Suhail    20:33, April 21, 2013 (UTC)


 * The current problem is that AjaxRC reads in ajaxCallAgain only when AjaxRC first runs. If another script runs after AjaxRC, anything added to ajaxCallAgain array after AjaxRC has already initialized is ignored. This is an unintended side effect of the most recent update to AjaxRC. It has been identified and fixed, but the fix is not live yet. I think Kangaroopower is making some other slight changes as well, but when he's ready Grunny can push the next update live which will fix this bug.


 * One thing you can do to help alleviate this bug in the meantime is, in your wiki's JS installation, make sure the AjaxRC import is at the bottom of your JS file so that it's the last thing that initializes.

ajCallAgain should be last event in AjaxComplete
Is there any particular reason why the ajCallAgain section is not last? -452 01:34, 23 May 2013‎ (UTC)


 * Apologies for not updating the talk page, but this bug has since been resolved and the fix is live. Or were you referring to something else? (please clarify what you mean by "ajCallAgain section")


 * There is currently a different problem with the same feature. Line 43-45 loops through ajCallAgain[].  Line 46-60 are applying other functions.  Any changes made in the ajCallAgain loop which are related to the subsequent functions are lost.
 * Specifically, there is a known problem with grouped recent changes which causes grouped Article comments and Message wall threads to be expanded by default. It hasn't been fixed in a year and I've been told that it's a low priority problem unlikely to be fixed any time soon, so I made a function "collapseExpandedGroups" to loop through ".mw-collapsible-toggle-expanded" and collapse them (on load, you can still toggle them afterwards).
 * Calling collapseExpandedGroups with ajaxCallAgain doesn't work because of the "$collapsibleElements.makeCollapsible;" on line 50, which is apparently the cause of the unfixed bug.
 * I've fixed it myself by just copying the script locally and moving the ajCallAgain section, but I figured it would be worth bringing up.  -452  03:08, May 23, 2013 (UTC)
 * So where did you fix it? -- Kangaroopowah  ( Talk ) 03:29, May 23, 2013 (UTC)
 * Locally on the wiki I use. -452 14:07, May 24, 2013 (UTC)


 * [Moved content under a new header, as this is a new issue]


 * @452 - Assuming Kangaroopower doesn't see any other problems with moving ajCallAgain to the bottom of the AjaxComplete callback, it sounds like a reasonable thing to do.


 * I believe it isn't necessary in the situation you described though.
 * In your ajaxCallAgain function, you could have called makeCollapsible yourself on those same elements, and then loop through them and collapse them afterwards. [Then, by the time AjaxRC's makeCollapsible call runs afterwards, the elements would have already been made collapsible and the code shouldn't run again.]
 * Or add class="mw-collapsed" to those elements before calling makeCollapsible. [Not sure if this would work if we moved ajCallAgain to the bottom of the AjaxComplete callback as you are proposing &mdash; that would cause AjaxRC's makeCollapsible to run before you've had a chance to add class="mw-collapsed" to the elements, and so I don't think they'd be in a collapsed state.]


 * I'm sorry that I've given you insufficient information about the nature of the bug.
 * Those elements are class="mw-collapsed", I'm not adding it, I'm just calling "click" on anything that is expanded. (As I said: loop through ".mw-collapsible-toggle-expanded" and collapse them)
 * I don't know the exact cause of the bug, Wikia have acknowledged that they should be collapsed and concur with my findings that toggle state of those elements in permanently reversed: "mw-collapsed" is removed when they are actually collapsed, and "mw-collapsed" re-added when they're expanded - the opposite of all other collapsible tables on RC.
 * -452 14:07, May 24, 2013 (UTC)

(reset indent) @452: Ah, I see. I think you gave me enough information, but I didn't take the time to actually reproduce the bug before replying. Now that I have, I see what you mean. Sorry about that.

On a related note, since I was playing around with it, here is a CSS fix I came up with for the issue, in case you or anyone else would have a use for it. One advantage (disadvantage?) to this is that it kills the fadeOut animation.


 * I personally am against a CSS solution because of the amount of space it'll take up. Unless there are any side effects to 452's fix, I suggest we push it. @452, submit your patch too AjaxRC/beta.js and then go to Portal:Code review so we can take a more in depth look at it and then we'll go from there. -- Kangaroopowah  ( Talk ) 02:42, May 26, 2013 (UTC)


 * Changes made. Do you want me to reply to Portal:Code_Review/AjaxRC or make a new post? -452  02:55, May 26, 2013 (UTC)


 * @Kangaroo: To clarify, I'm on board with 452's suggestion of moving ajCallAgain to the bottom of the callback. As far as changes to AjaxRC, I believe that's the only thing that needs to / should be done here, as seen in http://dev.wikia.com/?diff=12300.


 * I do not think either of us were (or to speak for myself, I was not) suggesting to include a fix for the grouped recent changes bug in AjaxRC itself, because 1) this is a very minor issue and 2) the purpose of AjaxRC isn't really to fix Wikia's bugs.


 * The reason I posted the CSS above was not for inclusion in AjaxRC, but as one possible solution for people reading this page who want to fix the bug on their own, in the event that Wikia doesn't fix it anytime soon (if ever).


 * @Math that makes more sense. I was more concerned with the ajaxCallAgain bug in general, but the css kinda threw me off :P. Thanks for clarifying, and I agree that AjaxRC shouldn't be fixing Wikia's RC bugs (this depends though, on how much the bug in question affects AjaxRC IMO). @452 just create a new one, like.

Memory leak
There appears to be a memory leak caused by using this script.

I'm using google chrome, which has a handy task manager which tells you the memory usage of each tab. When I open RecentChanges and leave it sit open, the memory usage goes higher and higher, resulting in a lot of lag if the tab is left open all day or overnight.

I haven't really looked into it yet, so I don't know whether it's a problem with the script not deleting unused variables, or whether javascript just has poor memory management. -452 02:19, June 1, 2013 (UTC)
 * See my talk for details. We're not exactly sure of the problem, but my change did fix it on my end so I'm going to push it along with your fix. -- Kangaroopowah  ( Talk ) 02:39, June 1, 2013 (UTC)


 * Great, thanks! -452 02:48, June 1, 2013 (UTC)


 * Just after my last reply, I copied over "$temp.remove;", waited a little while for the cache to update, then left the tab open until now. That tab is now using over 500mb. All of it in "Javascript memory". I'll repeat the experiment with the MakeCollapsible part disabled. -452 13:03, June 1, 2013 (UTC)


 * @452: Oh cool, you're looking into it here too. Please do share your findings and hopefully we can track it down - memory leaks are nasty business.


 * I opened two Recentchanges tabs just after my last comment: Tab with makeCollapsible enabled: 434mb. Tab with makeCollapsible disabled: 44mb. So I definitely agree with you that makeCollapsible is part of the problem. Whatever makeCollapsible is adding is not being properly removed when the page is reloaded, I don't know if that's a problem with makeCollapsible itself claiming some memory when it is called, or if AjaxRC isn't freeing some memory when the refresh happens.
 * I googled it and found a post from last year about a similar makeCollapsible problem elsewhere, and another post about makeCollapsible using a lot of memory when used a bunch of times on the same page, but because this is a unique case of calling makeCollapsible over and over, no-one has really paid attention to how much memory it eats.
 * Here's the wikia source for makeCollapsible: https://github.com/Wikia/app/blob/dev/resources/jquery/jquery.makeCollapsible.js
 * Since the bug isn't really an issue without AjaxRC, it's probably unlikely to be fixed there, so it may be a matter of writing a function in AjaxRC to undo everything that makeCollapsible does, that is to say, correctly unload/delete anything makeCollapsible has added, before refreshing the content and calling makeCollapsible again. Unfortunately, there isn't already a "makeUnCollapsible". -452 19:18, June 1, 2013 (UTC)


 * After reading your comments on Kangaroopower's talk page, I did some more searching and found this stackoverflow: how to remove dom elements without memory leaks. If that's accurate, it explains why the problem exists. With this in mind, I'm going to do some more tests with blanking nodes before replacing them. -452 22:29, June 1, 2013 (UTC)


 * I had no luck testing, and have had no bright ideas about how to fix it, however, running this line in the console over and indicates that it's entirely a problem with makeCollapsible, since the nodecount increases every time it is run:

$( '.mw-collapsible' ).makeCollapsible; var count=0; for (var i in jQuery.cache) count++; console.log("nodes: "+count);
 * Right now, there's 16 collapsible entries on my recentchanges, and it's adding 16 nodes every time it is run, both when allowing ajaxrc to refresh, and when just running it repeatedly from the console. -452 20:39, June 12, 2013 (UTC)


 * Cool, it sounds like you and I at least are on the same page about that. (I've been convinced it was a makeCollapsible problem since about a month ago.) Still would like to hear back from Kangaroopower/Grunny/Kirkburn. Seems to me like the easiest, no effort no brainer "fix" would be to just be to remove makeCollapsible from AjaxRC. Obviously we'd prefer to have collapsible elements, but in my opinion &mdash; in the short term &mdash; fixing the memory leak is more important than having fancy collapsing doodads that aren't absolutely necessary. But that's Grunny's call to make.

Maybe the problem is not  as such but replaceWith. doesn't destroy any elements and it doesn't remove data-objects and events either. It simply detaches all of it from the DOM and returns it. The code may not use the return value, but the elements are probably not removed from memory regardless, because the data-objects and events are still attached:

Empty however removes everything - including data and events - from memory:

Just an idea. --


 * It's a good idea, I was experimenting with empty myself. But that's why I posted my example: even when used by itself, makeCollapsible creates X nodes every time it is called, where X is the number of collapsible elements on the page. (I tried your example, and the node count still increases by X every time AjaxRC runs, unfortunately.) -452 09:19, June 14, 2013 (UTC)


 * I don't understand. Whatever nodes  adds would be childnodes of


 * , would they not? So why would  not remove them? O_o


 * Is there a specific scenario where this memory leak occurs? Collapsible basic elements? Collapsible lists? Collapsible tables? Custom collapse tags? --


 * I don't understand it either, it's certainly a puzzler. My theory is that  is declaring a global variable and keeping an array of nodes, so they're still referenced and not deleted by  . But as I've not actually looked into it, that's purely speculation.
 * Your solution is good, it fixes all problems except the basic makeCollapsible problem, which can be proved to be still occurring by counting the nodes as Mathmagician suggested.
 * I'm counting the nodes at the start and end of loadPageData, and immediately before and after calling makeCollapsible.
 * With your code, when there is no change to RecentChanges, there is no change to the node count, but immediately after makeCollapsible, there is an increase of X nodes - which exactly the same as when just running makeCollapsible from the console.
 * No specific scenario, just normal "grouped recent changes". -452 09:43, June 14, 2013 (UTC)


 * There's no need to speculate about what  does. The code is here. And I see no global variables... Hm. --


 * There are a bunch of closures, though. Maybe there's a circular reference somewhere... --


 * I just remembered what I read 2 weeks ago: There is a known problem with onclick handler not being dealt with correctly by .   definitely should add X number of onclick handlers when it is called, so apart from the fact that it's apparently not checking for existing handlers each time you call it, it may not even be a problem with , it's just that when you call  , they're not being removed properly. -452 15:17, June 14, 2013 (UTC)

Here's a simple test you can run on any mediaWiki page from the console:

It does not appear that  causes memory leaks. --


 * Good to know, at least we now know it must definitely be a problem with AjaxRC. -452 18:33, June 14, 2013 (UTC)


 * Well, it seems AJAX caching is the culprit:




 * But disabling AJAX caching ($.ajaxSetup({ cache: false });) also causes the collapsible elements to not work at all. No "collapse/expand" arrow is visible in RecentChanges for me when I tested the script with your new loadPageData function.


 * Yup. That's correct. I was kind of hoping it was only the images that are failing to load, but turning off caching makes it indeed necessary to run  again. Which causes memory leaks. Which brings us full circle back to  . Again. *sigh*


 * Soooo... Is there something wrong with the test code for  I posted above? Or is this test somehow different from Special:RecentChanges? Does the custom toggle for the collapsible cause   to leak? --

There appears to be a circular reference in. It's in  in line #55. refers to the element that gets collapsed or expanded. The callback gets attached to the toggle-button and runs after the fadeOut/In. I would think the collapsible cannot be garbage-collected because this event-handler of one its child-elements holds a reference to it. And since the garbage collector stops at the collapsible it never reaches the child with the event-handler. Does that make sense? --


 * Line #55? Line #55 is a comment and I couldn't pinpoint . Just to make sure we're talking about the same thing: source code on Github: makeCollapsible. Note: I haven't reviewed makeCollapsible's source code for any potential problems yet. I was kind of hoping the problem was with the interface between AjaxRC and makeCollapsible, rather than inside makeCollapsible itself...
 * Pecoes is talking about this: git.wikimedia.org. -452 16:16, June 15, 2013 (UTC)


 * The version at git.wikimedia.org is clearly newer. Not just according to its date. It also replaces outdated stuff like  with current stuff like  . But Math has a point – as usual. For our purposes it's the older version Wikia uses, that counts. Now we need to look for the bug in two versions. On top of everything else. Awesome. --


 * If this is indeed a makeCollapsible bug (have we definitively reached that conclusion?) that is no fault of AjaxRC, I feel like it should be treated as a separate issue at this point, and that we should follow up with Kirkburn and Grunny for clarification on what should happen next.

Here is some reproduce code. I kept it as simple as possible, but I also tried to mimick Special:RecentChanges as much as possible. That's why it turned out a bit lengthy. It's meant to be tested via the console and it only works properly on Special:RecentChanges - but that's mainly because the relevant bits of CSS don't get loaded on other pages.

'   )    .appendTo('#mw-content-text')    .makeCollapsible    .find('button')    .click(function  { var c = 0, i;       for (i in jQuery.cache) c++; console.log('Test', t, 'jQuery.cache', c); test(t + 1); }); }(1)); --


 * Hey guys, as a heads-up I'm on vacation right now so if you don't mind Math, can you maintain this script for a bit until I come back? The only favor I'd like to ask on top of that is to leave a message on my talk when you're going to push a new change to /code.js. I might not see it immediately, but it would be nice as reference. Thanks, -- Kangaroopowah  ( Talk ) 04:56, June 16, 2013 (UTC)


 * I'm with Math here. Since this does not seem to have anything to do with AjaxRC, there's not much more that needs to be discussed here. It may be wise to contact Grunny or Kirkburn as Math suggested. In any case I filed a bug report at wikimedia.org. --


 * I left a Special:Contact message for Grunny and Kirkburn. Hopefully we'll hear back from them sometime soon.


 * Note: I heard back from Kirkbirn: he mentioned that he would pass this one on to someone more technically inclined. Who that is or whether it happens anytime soon or not is anyone's guess...


 * Kirkburn reported the bug in a ticket, and it's in my queue. A patch has been submitted by a volunteer to MediaWiki core to fix this already (before it even entered Wikia's bugtracker! :)). I'm waiting for a few more reviews to be made to the patch before backporting it to Wikia; I'll test their patch soon either way and commit it to our repo. Cheers, grunny  :&#126;$ 11:13, June 26, 2013 (UTC)


 * Just an update. I backported their fix to our MW version and committed it. It will be released in just under two weeks. :) Cheers, grunny  :&#126;$ 15:39, August 9, 2013 (UTC)

Running on first load
Line 66 is, is there any reason not to use   there instead so that the page isn't immediately refreshed? -452 13:30, June 16, 2013 (UTC)

ajaxCallAgain and namespace checks
I've added a little more documentation regarding ajaxCallAgain. Would I be correct in thinking ajaxCallAgain is checked with every iteration, meaning it can be added to at any point? This would be opposed to the other variables that are checked once as the script loads and not at any point after. It would appear that the functions being added to the array need to have their variables defined within that function instead of in an outer function, for example: causes errors (as I would expect). There's not very much documentation on it anyway, although it's probably a bit beyond the average person who's importing the script to their wiki.

I've also removed the namespace checks for  and. wgCanonicalSpecialPageName returns a boolean (false) if it's not in the Special namespace and a string if it is. Either way, it appears perfectly safe to remove the wgNameSpace checks for those 2 conditionals.

Memory Leak - Firefox
Hello, I seem to be experiencing a similar issue regarding a memory leak when AjaxRC is used as mentioned on Talk:AjaxRC (Same page, just a different section). I have ruled out other possibilities but after installing this the memory leak is revealed. While it seems the previous conversation said it was fixed, it was either undone at some point since then or a new leak has arisen via Firefox ver 27.0.1 03:34, March 4, 2014 (UTC)


 * That was a bug with jquery.makeCollapsible and was fixed. The module hasn't been touched since afaik. Do you have a link to where you're seeing the leak?


 * Double checked, jquery.makeCollapsible.js hasn't been edited in 7 months.


 * It is being used on the Hexxit Wiki. After it runs an hour or two, without intervention, the memory leak is much more noticeable. Disabling it and leaving it as if it were running, the memory leak becomes much more apparent as firefox hardly changes in RAM usage with it disabled. 00:10, March 5, 2014 (UTC)


 * I had a talk with Grunny who seems to think it's possible this could be an issue with Firefox which apparently has a history of memory issues. I'd suggest trying out Chrome instead and seeing if the problems persist across browsers.

Auto-updating modules
Is it possible for this script to auto-update individual elements such as the side-rail modules, like Chat, RecentActivity, etc, without refreshing the entire page?