Closed Bug 1167989 Opened 5 years ago Closed 4 years ago

[e10s] Add API for iterating over all (content) windows

Categories

(Firefox :: Extension Compatibility, enhancement)

enhancement
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
e10s + ---
firefox41 --- affected

People

(Reporter: hultmann, Unassigned)

References

Details

Sometimes extension code running in the chrome process needs to know what content windows are opened.

It is a trivial task for non-e10s code, but currently for e10s it requires too much work.

For example, it is useful for network/TabSelect observers.

I suggest something like the following.

=======8<-------

var map = Components.utils.winMap;
var innerId;

innerId = channel.loadInfo.innerWindowID;
innerId = map.getCurrentInnerId(tab.linkedBrowser.outerWindowID);

map.getOuterId(innerId);
map.getUrl(innerId);        // "https://www.mozilla.org/"
map.getParent(innerId);     // 17
map.getTop(innerId);        // 11
map.getOpener(innerId);     // -1
map.getFrames(innerId);     // [21, 22, 23]
map.getTopContentWindows(); // [11, 12, 13, 14, 15] (i.e. 5 tabs)
map.isContent(innerId);     // true
map.getAllWindows();        // [11, 21, ...] // chrome windows too?


// observers, so I can keep the data in a worker thread:

var obs = {
  observe: function(subject, topic, data) {
    var innerId = subject.QueryInterface(Ci.nsISupportsPRUint64).data;
    console.log("new window: " + Cu.winMap.getUrl(innerId));
  
    var outerId = map.getOuterId(map.getTop(innerId));
    var browser = tabbrowser.getBrowserForOuterWindowID(outerId);
  }
};

Services.obs.addObserver(obs, "inner-window-added", false);
// and "inner-window-removed"
Adblock Plus has a use case for it.
> Something we really need is a way to go from window/parentWindowId to the corresponding URL

https://issues.adblockplus.org/ticket/2504#comment:8
Blocks: e10s-addons
> It is a trivial task for non-e10s code
> but currently for e10s it requires too much work.

imo it would be better for everyone to have a solution that reduces the boilerplate code that's needed for asynchronously talking to content (and getting return values, not just 1-way messages) instead of adding specialized code for every specific use-case. outlined my thoughts in bug 1147592.
It's been a year and no-one has picked this up. It sounds like it is possible, to do this right now, but could be simpler. Given the move to WebExtensions, I'm tempted to close as won't fix on this. Any objections?
I'm the reporter for this bug, and I have no objections.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.