SDK

Roundtable

Websockets Issue in FX 18 ( bug 817669 ): The code works on release and aurora, broken in beta & nightly. This breaks the OnePassword add-on. Gabor's bisecting to try to find the change that broke it. We don't yet know why it's broken and what fixed it in Aurora. We have four weeks until the current Firefox Beta (18) is released. If we have a fix in 2 weeks we have a good chance of getting it uplifted to Beta, on the basis that it breaks an important add-on. It's kind of a hack, what they are doing. Is there a better way to do it, and should we encourage OnePassword people to do that in future? Like, running the web socket in a content script and passing the data back to the main add-on. Regardless, we still have to fix this problem now.

Test failures on central/inbound since last Wednesday: bug 817670. Seems that a change in JS engine in Firefox caused it. Who can look into it? Gabor's full, Eddy might have time.

Per-window private browsing: Sounds like things are just about ready to land to central. Are we ready? Erik: there is a problem with panel, that's moved between hidden window and browser window when it's shown. Should we do what Google chrome does, where add-ons by default can't run in private browsing windows?

Also, where are we at with the twig repo? Not very far. We have a clean twig (temporary branch of moz-central) which we will use to test landing the SDK in Firefox.

Tanvi is implementing mixed content blocker. This will block HTTP content that's loaded from HTTPS pages. To do that we need to determine the origin for content scripts that attempt XHR. What do we want to do here? When content scripts are attached to HTTPS pages, they should only be allowed to perform XHR to pages that are also served over HTTPS. But the expanded principal lists all possible origins. We need to know the *actual* origin in this particular case. What if we made the actual origin the first in the list? That would work. Note that add-ons can do cross-domain xhr anyway, just not in content scripts. But this is OK, out of scope for the mixed content blocker.