653917 - ...tabs.activeTab.contentWindow is undefined

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Greg K.]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Build Identifier: 1.0b5 rc1

The following code worked fine in 1.04b, returns null or undefined in 1.05b rc1:

const windows = require("windows");
var subWin = windows.browserWindows.activeWindow.tabs.activeTab.contentWindow;
    or:
subWin = windows.browserWindows[i].tabs.activeTab.contentWindow;



Reproducible: Always

Steps to Reproduce:
1. Create a new project
2. Modify main.js to just have:

const windows = require("windows");
var subWin = windows.browserWindows.activeWindow.tabs.activeTab.contentWindow;
console.log("subWin = " + subWin);
subWin = windows.browserWindows[0].tabs.activeTab.contentWindow;
console.log("subWin = " + subWin);


Actual Results:  
Run it with 1.05b rc1, you'll get the output:

info: subWin = undefined
info: subWin = undefined

Expected Results:  
Same code run with 1.04b release gives:

info: subWin = [object XrayWrapper [object Window]]
info: subWin = [object XrayWrapper [object Window]]

Comment 1

[Myk Melez [:myk] [@mykmelez]]

This is actually an intentional change.  The Tabs API is designed to work across processes, and it isn't possible to pass a DOM window like the value of .contentWindow from one process to another.

You can, however, attach a content script to the tab that does have access to the DOM Window object of page loaded in the tab.  To do so, see the .attach() method of Tab objects.

Comment 2

[Greg K.]

Thank you, Myk. I found an alternative way of doing what I need for now. I do hope though, that there won't be too many such changes in the future, taking away features that work now and breaking the existing code.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Yes, we very much want to maintain API compatibility going forward!  A large part of the reason we made the last set of breaking changes was to prepare for anticipated future changes to the platform (in particular separate processes for content and addons), so that we don't have to break APIs when they happen.

As we approach the 1.0 stable release, and into the future, you should see much less churn (approaching none) in the stable high-level APIs in addon-kit (experimental and internal APIs like those in api-utils are still subject to change, however).