36423 2010-03-20 22:45:33 -0700 Object.defineProperty cannot be used to set id of Div element, Element/HTMLDivElement prototype 2022-05-31 10:29:49 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED P2 Major --- 0 t.brain webkit-unassigned ahmad.saleem792 amla70 ap arv barraclough ggaren john.david.dalton oliver p.jacquemart t.brain wkenjackson oldest_to_newest 202269 0 51241 t.brain 2010-03-20 22:45:33 -0700 Created attachment 51241 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. 202312 1 oliver 2010-03-21 13:35:56 -0700 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. 202317 2 t.brain 2010-03-21 14:23:58 -0700 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. 202318 3 oliver 2010-03-21 14:28:16 -0700 (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. 444424 4 amla70 2011-07-31 11:34:58 -0700 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. 576251 5 t.brain 2012-03-12 10:34:15 -0700 Won't this be fixed now under Bug 49739? 576279 6 barraclough 2012-03-12 11:01:13 -0700 (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. 636564 7 wkenjackson 2012-05-29 16:53:00 -0700 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. 1872827 8 ahmad.saleem792 2022-05-30 15:01:09 -0700 I just tried the attached test case with Safari 15.5 and it shows "Pass" for all sub-test cases (four times dialog popped-up) similar to other browsers like Firefox Nightly 102 and Chrome Canary 104. Should this be marked as "Resolved Fixed" or "Resolved Invalid". Thanks! 1873034 9 ap 2022-05-31 10:29:41 -0700 Thank you for checking! 51241 2010-03-20 22:45:33 -0700 2010-03-20 22:45:33 -0700 Object.defineProperty cross-browser testcase defineProperty.html text/html 1317 t.brain PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIiAiaHR0cDov L3d3dy53My5vcmcvVFIvaHRtbDQvc3RyaWN0LmR0ZCI+DQo8aHRtbD4NCjxoZWFkPg0KPHNjcmlw dCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPg0KdmFyIGVsPWRvY3VtZW50LmNyZWF0ZUVsZW1lbnQo ImRpdiIpOw0KDQovLyBPdmVycmlkZSB0aGUgcHJvcGVydHkgb24gdGhlIEVsZW1lbnQgcHJvdG90 eXBlDQovLyBQQVNTOiBJRTgsIElFOQ0KLy8gRkFJTDogV2ViS2l0LCBGRjMuNw0KdHJ5IHsNCglP YmplY3QuZGVmaW5lUHJvcGVydHkoRWxlbWVudC5wcm90b3R5cGUsImlkIix7IGdldDpmdW5jdGlv biAoKSB7IHJldHVybiAiYSI7IH0gfSk7DQoNCglhbGVydChlbC5pZD09PSJhIiA/ICJQQVNTIiA6 ICJGQUlMIik7DQp9IGNhdGNoIChlKSB7DQoJYWxlcnQoIkVSUk9SOiAiK2UubWVzc2FnZSk7DQp9 DQoNCi8vIE92ZXJyaWRlIHRoZSBwcm9wZXJ0eSBvbiB0aGUgSFRNTERpdkVsZW1lbnQgcHJvdG90 eXBlDQovLyBQQVNTOiBJRTgsIElFOSwgRkYzLjcNCi8vIEZBSUw6IFdlYktpdA0KdHJ5IHsNCglP YmplY3QuZGVmaW5lUHJvcGVydHkoSFRNTERpdkVsZW1lbnQucHJvdG90eXBlLCJpZCIseyBnZXQ6 ZnVuY3Rpb24gKCkgeyByZXR1cm4gImIiOyB9IH0pOw0KDQoJYWxlcnQoZWwuaWQ9PT0iYiIgPyAi UEFTUyIgOiAiRkFJTCIpOw0KfSBjYXRjaCAoZSkgew0KCWFsZXJ0KCJFUlJPUjogIitlLm1lc3Nh Z2UpOw0KfQ0KDQovLyBPdmVycmlkZSB0aGUgcHJvcGVydHkgb24gYSBESVYgZWxlbWVudA0KLy8g UEFTUzogSUU4LCBJRTksIEZGMy43DQovLyBGQUlMOiBXZWJLaXQNCnRyeSB7DQoJT2JqZWN0LmRl ZmluZVByb3BlcnR5KGVsLCJpZCIseyBnZXQ6ZnVuY3Rpb24gKCkgeyByZXR1cm4gImMiOyB9IH0p Ow0KDQoJYWxlcnQoZWwuaWQ9PT0iYyIgPyAiUEFTUyIgOiAiRkFJTCIpOw0KfSBjYXRjaCAoZSkg ew0KCWFsZXJ0KCJFUlJPUjogIitlLm1lc3NhZ2UpOw0KfQ0KDQovLyBEZWZpbmUgdGhlIHByb3Bl cnR5IG9uIGEgbm9uLURPTSBvYmplY3QNCi8vIFBBU1M6IElFOSwgV2ViS2l0LCBGRjMuNw0KLy8g RkFJTDogSUU4DQp0cnkgew0KCXZhciBvPXt9Ow0KDQoJT2JqZWN0LmRlZmluZVByb3BlcnR5KG8s ImlkIix7IGdldDpmdW5jdGlvbiAoKSB7IHJldHVybiAiYyI7IH0gfSk7DQoNCglhbGVydChvLmlk PT09ImMiID8gIlBBU1MiIDogIkZBSUwiKTsNCn0gY2F0Y2ggKGUpIHsNCglhbGVydCgiRVJST1I6 ICIrZS5tZXNzYWdlKTsNCn0NCjwvc2NyaXB0Pg0KPC9oZWFkPg0KPGJvZHk+DQo8L2JvZHk+DQo8 L2h0bWw+