567758 - Objects derived from events (as __proto__) are subject to the same read-only policy for event properties

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Luke Smith]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100513 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100513 Firefox/3.6.4

This may be a dup, but I couldn't find an original ticket.

Wrapping an event either by
var wrapper = {};
wrapper.__proto__ = e;

or
function F() {}
F.prototype = e;
var wrapper = new F();

creates an object that continues to throw "setting a property that has only a getter" for all own properties of the event.

Reproducible: Always

Steps to Reproduce:
document.addEventListener('click', function (e) {
    var wrapper = {};
    wrapper.__proto__ = e;
    e.type = "boom";
}, false);
Actual Results:  
Exception thrown by type assignment line: "setting a property that has only a getter"

Expected Results:  
Assignment should be applied.

@kangax mentioned a "fix" from @dhtmlkitchen that applied to Gecko 1.8.1.22, suggesting this has been around for a while.

http://github.com/GarrettS/ape-javascript-library/blob/master/test/yui-test/build/yuitest/yuitest-beta.js#L3457

Comment 1

[Boris Zbarsky [:bzbarsky]]

The issue is that |e| has a setter for the "type" property and that that setter throws.  So when you do the set, a property lookup for "type" finds that setter on the prototype chain and calls it...

The existence of that setter is something we're considering changing; there are existing bugs on that.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and given that the setter is there the js engine behavior is most certainly correct.

Comment 3

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Fixed with WebIDL bindings: the assignment is now a no-op in non-strict mode and an exception in strict mode, pe spec.