Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#14156 closed bug (notabug)

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.).

Change History (5)

comment:1 Changed 7 years ago by Rick Waldron

Resolution: notabug
Status: newclosed

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

comment:2 Changed 7 years ago by diego

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 ?

comment:3 Changed 7 years ago by Rick Waldron

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.

comment:4 Changed 7 years ago by diego

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.

comment:5 Changed 7 years ago by Rick Waldron

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 :)

Note: See TracTickets for help on using tickets.