Bug Tracker

#14156 closed bug (notabug)

Opened July 19, 2013 03:13PM UTC

Closed July 19, 2013 03:32PM UTC

Last modified July 19, 2013 06:27PM UTC

leaks in global

Reported by: diego Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 2.0.3
Keywords: Cc:
Blocked by: Blocking:
Description

I tested this on 2.0.4-pre edge in various browsers.

By just loading the jQuery script, using normal script tags, I noticed that a new variable is created in the global space.

The leaked variable is named something like:

jQuery204000306821325382433670.9723695468951311

and it contains the value '2'.

A quick inspection revealed the leak is created by this code:

    // The ready event handler and self cleanup method
    completed = function() {
        document.removeEventListener( "DOMContentLoaded", completed, false );
        window.removeEventListener( "load", completed, false );
        jQuery.ready();
    };

Commenting/removing the line jQuery.ready() solves the problem, also I know this is not the correct solution.

Further debugging showed the problem is created by the element "Data" code (key/get, expando, cache etc.).

Attachments (0)
Change History (5)

Changed July 19, 2013 03:32PM UTC by rwaldron comment:1

resolution: → notabug
status: new → closed

This is not a "leak" in the undesirable global bindings sense, is expected and is tested—so therefore not a bug.

Changed July 19, 2013 04:47PM UTC by diego comment:2

It hasn't create any problems for me yet, however I noticed the difference and I classified it as "bug" because modifying hosts objects we don't own was considered bad habit until recently.

This doesn't happens in jQuery 1.x versions and they were tested too.

Is this a new behavior we should account for in 2.x ?

How many of these global variables are expected to be there ?

Could you expand or point to information on why this is needed ?

Changed July 19, 2013 05:09PM UTC by rwaldron comment:3

In jQuery 2.0+, to efficiently store data by owner object key (O(1) lookup), the data api defines a value property whose descriptor is the defaul { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }, where the value is the cache key for that object. jQuery does this in jQuery 1.x as well, but not as nicely http://jsfiddle.net/rwaldron/v9DPG/, where the expando is just a normal property.

jQuery could remove that property once "ready" callbacks are fired and the events are no longer needed, but as soon as user code adds events to the window or document, or whatever else, the key will will reappear.

Changed July 19, 2013 06:13PM UTC by diego comment:4

Thank you Rick, I wasn't completely aware about this event/data mechanism.

If it were possible, it would be better to store those values internally to jQuery, though I am sure the team already evaluated that.

Changed July 19, 2013 06:27PM UTC by rwaldron comment:5

Indeed! My first draft of jQuery 2.0's data mechanism completely did away with expando properties and used dual arrays where the "index" array held references to the owner object and the value array held the data object at the corresponding index. This was elegant, but performed horribly, since it cost a linear O(n) lookup on each access to find the reference in the index array.

In a few months, IE11 will ship, which will give us 3 browsers that support WeakMap, which is my long term plan for the data storage mechanism :)