See bug 694775 comment 4 and following. Jeff, see bug 694775 comment 11 in particular.

Yeah, I don't understand how this is supposed to work. We need to implement nativeCall and then detect TestProtoSetterThis and ProtoSetterImpl and call our own instead? And then we need to reimplement whatever checks the engine is doing in those? That seem pretty brittle. Why exactly can't the engine do this itself? It knows exactly where the proto object is stored in the proxy object after all.

There's an argument that nativeCall is not well-adapted to this problem, certainly. In the original case, it made plenty of sense in that it meant that all proxy objects, that weren't recognized by the setter function as acceptable this-values, would be rejected. Generally there weren't many proxies that *wanted* settable protos, tho, so that part was perhaps somewhat vague. Probably what's most desirable here is making the prototype part of the proxy API, as in the getInheritance/setInheritance stuff from the latest ES6 drafts. That would make very clear to proxies how they could implement prototypy stuff.

Eric, do you have the bandwidth to maybe look into this?

This should just be fixed when 926012 lands. It no longer relies on implementing the extra machinery. If we want a backport, we can do that much more simply, but we wanted to take a step forward as we did this.

Fixed by the patch in bug 926012.