info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Exposing a custom chrome object via XPCCrossOriginWrapper / XOW
21 views
Skip to first unread message
ston...@gmail.com
Mar 21, 2014, 8:28:05 AM3/21/14
to
I'm trying to expose a chrome object to a webpage DOM, but also make it accessible cross-domain. Normally you'd use a chrome object wrapper and __exposedProps__ to achieve this. However there doesn't seem to be a mechanism to customise cross origin wrappers to return a custom object.
The bigger picture is that I'm trying to wrap the built-in postMessage function in a custom JavaScript function. Each time a content page is loaded, I replace window.postMessage with my own function. This works fine when a web page calls window.postMessage (my own function is returned via a COW), but not when a page does e.g. frames[0].postMessage - since a XOW is invoked which retuns the native function. The XOW functionality seems to be hardcoded.
What I'm trying to achieve overall is to write an extension that will 'break' the JavaScript debugger whenever a webpage calls postMessage, inspect the call stack at that point (to see what code called postMessage) and inspect/modify the postMessage parameters.
The bigger picture is that I'm trying to wrap the built-in postMessage function in a custom JavaScript function. Each time a content page is loaded, I replace window.postMessage with my own function. This works fine when a web page calls window.postMessage (my own function is returned via a COW), but not when a page does e.g. frames[0].postMessage - since a XOW is invoked which retuns the native function. The XOW functionality seems to be hardcoded.
What I'm trying to achieve overall is to write an extension that will 'break' the JavaScript debugger whenever a webpage calls postMessage, inspect the call stack at that point (to see what code called postMessage) and inspect/modify the postMessage parameters.
bobby...@gmail.com
Mar 21, 2014, 1:20:22 PM3/21/14
to
On Friday, March 21, 2014 9:28:05 AM UTC-3, ston...@gmail.com wrote:
> I'm trying to expose a chrome object to a webpage DOM, but also make it accessible cross-domain. Normally you'd use a chrome object wrapper and __exposedProps__ to achieve this. However there doesn't seem to be a mechanism to customise cross origin wrappers to return a custom object.
>
>
>
> The bigger picture is that I'm trying to wrap the built-in postMessage function in a custom JavaScript function. Each time a content page is loaded, I replace window.postMessage with my own function. This works fine when a web page calls window.postMessage (my own function is returned via a COW), but not when a page does e.g. frames[0].postMessage - since a XOW is invoked which retuns the native function. The XOW functionality seems to be hardcoded.
Yeah. Unfortunately, XOW stuff is really sensitive, and we don't want to open it up to arbitrary extension points. I've been working to overhaul the spec on them ( https://etherpad.mozilla.org/html5-cross-origin-objects ), and we want to be sure that we implement this stuff precisely.
> I'm trying to expose a chrome object to a webpage DOM, but also make it accessible cross-domain. Normally you'd use a chrome object wrapper and __exposedProps__ to achieve this. However there doesn't seem to be a mechanism to customise cross origin wrappers to return a custom object.
>
>
>
> The bigger picture is that I'm trying to wrap the built-in postMessage function in a custom JavaScript function. Each time a content page is loaded, I replace window.postMessage with my own function. This works fine when a web page calls window.postMessage (my own function is returned via a COW), but not when a page does e.g. frames[0].postMessage - since a XOW is invoked which retuns the native function. The XOW functionality seems to be hardcoded.
You could possibly instrument all of the getters that return windows (including the indexed getter on |window| itself) to return forwarding proxies that implement your custom behavior. That could be pretty tricky to get right without breaking web pages though. :-(
0 new messages