393669 - Calling a function on a XOW doesn't call the original function (calls the one that overwrote it)

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Jeff Walden [:Waldo]]

Calling an allAccess function on a window that's not same-origin with the caller calls the function that other window defined on itself, not the original.  In other words, a window which redefines window.blur can screw with the expectations (maybe do worse) of any other window that blurs it, or the same for any other allAccess method, most likely.

I ran into this while working on the patch for bug 387706.

Comment 1

[Jeff Walden [:Waldo]]

Er, this happens in Firefox 2 as well.  It doesn't happen in Safari, so it's not some web-compat idiocy I just don't know about, either.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

I don't know how I missed this before, but we really can't forward when resolving for a XOW. This seems like the easiest way to do it.

Comment 3

[Johnny Stenback (:jst)]

Comment on attachment 278207 [details] [diff] [review]
Fix

This will also make it so that if someone uses an object with an outer window as the objects prototype, we won't be forwarding resolves etc in that case either. Not sure we care. r+sr=jst if you think we don't.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Actually, I don't think that's the case. Looking at the code in js_LookupPropertyWithFlags, it looks like we pass the 'current' objet when looking up the property. This contrasts sharply with the get/set property hooks, which take the original object and call the derived hook's method.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk. (Thanks for the approval jst, I totally forgot about it ;-)).

Comment 6

[Daniel Veditz [:dveditz]]

We'll want this on the 2.0 branch when we take XOW

Comment 7

[Jeff Walden [:Waldo]]

This is tested by one of the tests in the recently-landed support for window.postMessage via bug 387706.