W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 27 Jan 2015 14:48:03 -0500
Message-ID: <54C7EB73.9050104@mit.edu>
To: "Mark S. Miller" <erights@google.com>
CC: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On 12/4/14 11:49 AM, Mark S. Miller wrote:
> On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> OK.  What do we do if we discover that throwing from the defineProperty call
>> with a non-configurable property descriptor is not web-compatible?
> What we always do

So just for the record, jQuery (at least all the 2.* versions I've 
looked at) contains that following bits:

   Data.prototype = {
	key: function( owner ) {
		var descriptor = {},
			// Secure it in a non-enumerable, non-writable property
			try {
				descriptor[ this.expando ] = { value: unlock };
				Object.defineProperties( owner, descriptor );

			// Support: Android < 4
			// Fallback to a less secure definition
			} catch ( e ) {
				descriptor[ this.expando ] = unlock;
				jQuery.extend( owner, descriptor );

This function is called from Data.prototype.get, which is called from 
jQuery.event.add.  So the upshot is that trying to add an event listener 
to the window via the jQuery API will hit this codepath.

Now the good news is that the try/catch _is_ present there, so this 
doesn't immediately break sites.  But it's something to watch out for, 
and we _will_ be changing the behavior of jQuery here in a way that the 
jQuery developers clearly think is undesirable.

Received on Tuesday, 27 January 2015 19:48:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC