Closed Bug 868859 Opened 7 years ago Closed 7 years ago

Find a way to proxy window.content


(Core :: General, defect)

Not set





(Reporter: evilpie, Assigned: evilpie)


(Blocks 1 open bug)



(2 files, 1 obsolete file)

Quite a few addons use window.content in chrome. I think we need to somehow give them window.contentWindow, which already works with CPOWs.
Worth pointing out that it's not only add-ons, there's quite a lot of code in browser.js and elsewhere that uses |window.content| or, more commonly, just |content|
I found a way to do this. Don't judge me.
Nicer and cleaner way as recommended by bz.
Now that CPOWs landed on central, I am going to start on making these patches land-able.
This patch adds browser.contentWindow, contentDocument and webProgess.DOMWindow.
Assignee: nobody → evilpies
Attachment #775941 - Flags: review?(felipc)
Attached patch refreshedSplinter Review
D'uh has been happening a lot lately.
Attachment #775941 - Attachment is obsolete: true
Attachment #775941 - Flags: review?(felipc)
Attachment #775943 - Flags: review?(felipc)
This is redefining |content| to return a jsval, because otherwise we couldn't return a CPOW. I am not sure if there is some way to only do this for chrome JS code, but I suspect not. So we end up doing the normal thing in GetContentScriptable, but if we are trying to get content on a chrome window from chrome code, we end up calling a new method of nsIBrowserDOMWindow, that just returns the current browsers contentWindow. This surprised me at first, but apparently there is only one of these chrome windows or something like that. I don't usually mess around with this code, so I hope it's not too bad.
Attachment #776085 - Flags: review?(bzbarsky)
Comment on attachment 776085 [details] [diff] [review]
the actual window.content patch.

>+++ b/dom/base/nsGlobalWindow.cpp
>+nsGlobalWindow::GetScriptableContent(JSContext* aCx, JS::Value* aVal)
>+      JS::Rooted<JS::Value> val(aCx);

This seems to be unused.

>+++ b/dom/interfaces/base/nsIBrowserDOMWindow.idl
>+  jsval getContentWindow();

Is there a reason this is not a |readonly attribute jsval contentWindow;|?

r=me with those addressed
Attachment #776085 - Flags: review?(bzbarsky) → review+
Comment on attachment 775943 [details] [diff] [review]

Review of attachment 775943 [details] [diff] [review]:

::: toolkit/content/browser-child.js
@@ +33,5 @@
> +    let win = docShell.QueryInterface(Ci.nsIInterfaceRequestor)
> +                      .getInterface(Ci.nsIDOMWindow);
> +    return {
> +      contentWindow: win,
> +      DOMWindow: aWebProgress.DOMWindow // DOMWindow is not necessarily the content-window.

can you explain a case where win != DOMWindow? is it for subframes?
Attachment #775943 - Flags: review?(felipc) → review+
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Depends on: 902013
You need to log in before you can comment on or make changes to this bug.