606582 - make Windows API compatible with e10s (electrolysis)

Status: RESOLVED WORKSFORME

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

Description

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

The Windows API should be made compatible with e10s (electrolysis).

Comment 1

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

Hmm, now that I've taken a closer look, I don't actually see any e10s issues with the current implementation of the window API.  There is no direct access to content, and no APIs make any implicit or explicit promises of synchronicity.

The API does expose Tab objects that expose content.  But it uses the tab-browser module to do so, whose e10s-compatibility work is probably better addressed as part of bug 593908 (which fixes would then be picked up by the windows API automagically).

There might be some issues with the documentation.  For example, this code sample suggests one might manipulate content after a window opens, although that isn't currently possible to do:

    // an onOpen listener
    windows.openWindow({
      url: "http://www.mysite.com",
      onOpen: function(window) {
        // do stuff like listen for content
        // loading.
      }
    });

But that's not particularly an e10s issue (unless we decide to expose content through the API; but then we'll be adding interfaces, which is for a separate bug).

cc:ing Atul for a second opinion just in case I'm missing anything.

Atul: do you see anything in the windows module that has an e10s issue?  The docs in question are https://jetpack.mozillalabs.com/sdk/0.9/docs/#module/addon-kit/windows.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

On e10s land, will we be able to access cross-process info in a blocking way? I say this because the windows module has e.g. a getter for the window title, and I'm wondering if we'll be able to keep that as a regular getter or make that an async callback with the data.

And I believe the same applies to the windows enumerator

Comment 3

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

According to bsmedberg over IRC, it's ok for code in an addon process to block on a cross-process call into the chrome process or (in the future) a content process.  It's just the other way around that is problematic (because it would freeze the user interface and, in the future, a content page).

Comment 4

[Benjamin Smedberg]

Yeah. It's probably ok to block content->jetpack, although currently there is no way to actually do this, because we don't have content processes, and it may introduce problems with deadlocks. But it's certainly ok to block jetpack on whatever you want, with the understanding that blocking calls require context switches and it's better to avoid them if you can.

Comment 5

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

Ok, in that case I'll resolve this as worksforme, but if someone finds an issue with the API that we've missed, feel free to reopen the bug to call it out.

Comment 6

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

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".