W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Violations of internal method invariants?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 31 Jul 2014 14:24:08 -0400
Message-ID: <53DA89C8.1020600@mit.edu>
To: Jason Orendorff <jason.orendorff@gmail.com>
CC: Tom Van Cutsem <tomvc.be@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On 7/31/14, 9:43 AM, Jason Orendorff wrote:
> On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Requiring a single namespace, such that adding an input and then removing it
>> would make a previous property with the same name as the input go away,
>> would actually be fairly annoying performance-wise, I suspect.
>
> Really? There are web pages that add inputs to forms in a tight loop?

Sure.  Simple example: a page that has a table.  The table is in a form 
and is used to organize and lay out the controls.  The table has a few 
hundred rows, each with several controls in it.

The page has UI to sort the table rows; it does this by reordering them 
in the DOM using insertion sort.

This is not a hypothetical example, by the way; I've certainly profiled 
pages of this sort before.

> Right Thing: I think [[PreventExtensions]] on these objects should
> always return false.

The Web IDL spec requires this already, fwiw:

   Platform objects implementing an interface that supports indexed or
   named properties cannot be fixed; if Object.freeze, Object.seal or
   Object.preventExtensions is called on one of these objects, the
   function MUST throw a TypeError.

If there is an actual hook it can hook into now to do that, so much the 
better.

> I think [[DefineProperty]] on these objects
> should return false if Desc.[[Configurable]] is false or if it's
> missing and would default to false.

This is not compatible with the HTML spec, sadly (and neither is the 
spec, as a result) for the following reason: HTMLDocument needs to be 
able to have a non-configurable own accessor property named "location".

It looks like Safari and Chrome do not implement this part of the spec 
(from <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19560>), for what 
that's worth, but get the web compat behavior actually needed via not 
following the HTML spec for other parts of named access on Document.

The simple thing here would be to return false unless the property name 
is one of the ones that Web IDL defines as unforgeable on the object.

> Alternative: Specify what Gecko does. Make non-configurable properties
> on these objects shadow even the named getter.

This is needed for HTMLDocument, as long as it has a non-configurable 
"location" property.

-Boris
Received on Thursday, 31 July 2014 18:24:38 UTC

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