Bug 36423 - Object.defineProperty cannot be used to set id of Div element, Element/HTMLDivElement prototype
Summary: Object.defineProperty cannot be used to set id of Div element, Element/HTMLDi...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-20 22:45 PDT by T. Brains
Modified: 2014-07-01 07:40 PDT (History)
9 users (show)

See Also:


Attachments
Object.defineProperty cross-browser testcase (1.29 KB, text/html)
2010-03-20 22:45 PDT, T. Brains
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description T. Brains 2010-03-20 22:45:33 PDT
Created attachment 51241 [details]
Object.defineProperty cross-browser testcase

In contrast with the implementation in IE8+ and FF3.7, WebKit ignores properties which collide with native properties on DOM prototypes, and throws an error when trying to define any property on a DOM element.

This was tested against WebKit nightly r56152, Mozilla Developer Preview 3.7 alpha 3, Internet Explorer 8 and Internet Explorer Platform Preview 1.9.7745.6019.
Comment 1 Oliver Hunt 2010-03-21 13:35:56 PDT
Trying to override the getter on the prototype of an element is somewhat pointless as WebKit does not use getters for DOM properties.  Technically we could make it do so, but that basically means throwing away performance for no good reason.
Comment 2 T. Brains 2010-03-21 14:23:58 PDT
That means there's absolutely no way to override or extend the default get or set behavior of any of the built-in DOM properties, which is very limiting, and like I mentioned contradicts the behavior of other browsers.
Comment 3 Oliver Hunt 2010-03-21 14:28:16 PDT
(In reply to comment #2)
> That means there's absolutely no way to override or extend the default get or
> set behavior of any of the built-in DOM properties, which is very limiting, and
> like I mentioned contradicts the behavior of other browsers.

What is a use case for overriding "id", etc?  Understand that for you to have this misfeature then the DOM must be slowed down for all other uses.
Comment 4 Alfonso Martínez de Lizarrondo 2011-07-31 11:34:58 PDT
A use case for overriding a native property is described here: http://alfonsoml.blogspot.com/2009/09/hooking-textareavalue-with-ckeditor.html

By overriding the "value" of a textarea, it's possible to use CKEditor but at the same time keep using the same scripts on the page that used to work with plain textareas.

Sure, it's not a ground breaking feature, but it can be nice to have, because based on this feature it could be possible to map even more properties to make the use of existing code integrate automatically with CKEditor.

Currently if anyone uses the provided script they must tell their users that Safari isn't supported. It can try to be fast, but it doesn't do the job that it's expected to do.
Comment 5 T. Brains 2012-03-12 10:34:15 PDT
Won't this be fixed now under Bug 49739?
Comment 6 Gavin Barraclough 2012-03-12 11:01:13 PDT
(In reply to comment #5)
> Won't this be fixed now under Bug 49739?

I wasn't  sure! - assuming that 'id' should be further up the prototype chain than the Element prototype, then I guess so.  Since this bug was about more than just direct properties on instances I was conservative & decided not to dupe, but I think you're probably right, it probably is just the same issue.
Comment 7 Ken Jackson 2012-05-29 16:53:00 PDT
I've had similar problems in trying to define a getter for the 'src' attribute of DOM img elements without using prototypes.  Many DOM elements have property descriptors where configurable is set to false in webkit/JSC.

Note that in Safari 5.1.6, the 3rd test from comment #1:

> // Override the property on a DIV element
> // PASS: IE8, IE9, FF3.7
> // FAIL: WebKit
> try {
>    Object.defineProperty(el,"id",{ get:function () { return "c"; } });
>    alert(el.id==="c" ? "PASS" : "FAIL");
> } catch (e) {
>    alert("ERROR: "+e.message);
> }

fails and displays an alert "ERROR: Attempting to change access mechanism for an unconfigurable property" and this test does not use the prototype chain.

This test passes in IE8, IE9, FF3.7 and Chrome 19.0.1084.52.

Object.getOwnPropertyDescriptor(el, 'id').configurable returns false in Safari 5.1.6 for this test but returns true in other browsers.   It would be nice if webkit/JSC behaved in a manner that was consistent with other browsers.