Bug Tracker

Ticket #3763 (closed bug: invalid)

Opened 6 years ago

Last modified 6 years ago

attr() function's nodeType filtering isn't comprehensive

Reported by: amikitik Owned by:
Priority: minor Milestone: 1.3
Component: core Version: 1.2.6
Keywords: Cc:
Blocking: Blocked by:

Description

While this is likely a rare edge case, given the following code any attribute calls on generated DOM object (not pre-existing ones) will produce an error:

Object.prototype['testing'] = function (name) {
  var that = this,
    method = that[name];
  return function () { return method.apply(that, arguments); }
}
    
var b = $('<p>Example</p>');
b.css('display', 'block');

The fix for this is attached.

Attachments

fix-attr.patch Download (445 bytes) - added by amikitik 6 years ago.

Change History

Changed 6 years ago by amikitik

comment:1 Changed 6 years ago by amikitik

Issue seems to still exist in the nightlies.

comment:2 Changed 6 years ago by amikitik

While it's not smart to unconditionally add something to every object (like the function in the example), the code above exposes a potential problem.

Upon deeper investigation, jQuery uses 'in' loops quite a lot. If someone were to add something to the prototype of an object that jQuery loops over (say a function), then a loop over the elements could encounter unexpected type (string operations on a function). This could be avoided if every 'in' loop filtered the object with hasOwnProperty(). However, that seems like a performance penalty for a problem that really only manifests under unusual conditions (objects the get generated with additional prototype elements).

So file under "don't do that", I suppose? Or is there a built-in way to avoid this?

comment:3 Changed 6 years ago by dmethvin

  • Status changed from new to closed
  • Resolution set to invalid

jQuery does not support changes to Object.prototype. The additional Object properties become visible to for-in loops and breaks any code that uses them.

Note: See TracTickets for help on using tickets.