Would we be able to pass in a number of variables to the functions
such as show and hide which are initialised outside of the closures,
rather than store references to the "this" object.
I attempted to refactor/modify the code as a quick test but I kept
getting null references to things like the t
thanks for that explanation, Dave.
--Karl
On Oct 26, 2009, at 7:54 PM, Dave Methvin wrote:
I think a lot of plugins have this problem but most people aren't
creating and deleting them a lot. My splitter has this issue but I
solved that problem because I was too lazy to support splitters bein
I think a lot of plugins have this problem but most people aren't
creating and deleting them a lot. My splitter has this issue but I
solved that problem because I was too lazy to support splitters being
destroyed. See, the real problem is that you have a "destroy"
option! :-)
Since $this and oth
On Oct 25, 2009, at 8:42 PM, Andrew Tan wrote:
The memory is released when you refresh the page.
However, the users of my web app will be using the same page for 8+
hours a day and the page will most likely not be refreshed since all
the updates are displayed and retrieved via ajax and jquery.
I had the same problem with one of my application at work, that
refresh data in divs by ajax, with cluetips. The user would stay on
the page for 5/6 hours, with IE. So the only "workaround" I found was
to force a refresh of the page every 15 minutes. It's a page that
restore what was opened on the
The memory is released when you refresh the page.
However, the users of my web app will be using the same page for 8+
hours a day and the page will most likely not be refreshed since all
the updates are displayed and retrieved via ajax and jquery.
Wow, I wasn't aware of this memory leak at all. Thanks for bringing it
to my attention. I had no idea that storing the current element in a
variable would cause a leak. That's a really common thing to do in
jQuery plugins. I wonder if the memory issue has been encountered in
other plugins a
7 matches
Mail list logo
