822909 - Use mozbrowser type iframe for addon frames

Status: RESOLVED INCOMPLETE

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

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

At the moment SDK makes use of xul frames in the hiddenWindow to obtain a content type document with `top` null. But since only OSX has a hidden window with a xul document it's not possible (or is it ?) to create xul iframes there. To workaround this fact we do something more complicated, we create an html iframe in the hidden window, load xul document "chrome://global/content/mozilla.xhtml" into it:

https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/frame/hidden-frame.js#L56-L78

Once xul document is loaded, we create another a **xul** iframe that has content type and use then we use it to loads add-on related content:

https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/frame/hidden-frame.js#L130-L142

I suspect there is a better way to do this, it also seems to me that firefox OS run into same problems that's why HTML iframes there have mozapp, mozbrowser and remote attributes:
https://developer.mozilla.org/en-US/docs/HTML/Element/iframe

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

It looks like only thing stopping us from using html frame is that swapFrameLoaders is not implemented for them:

http://dxr.mozilla.org/mozilla-central/content/html/content/src/nsGenericHTMLFrameElement.cpp.html#l146

Fixing that would allow us to use html iframes.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

This is basically what I end up with, but swapping frame loaders fails presumably because of the line in the previous comment:

https://gist.github.com/4342219

Comment 3

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Is this still needed?

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Yes we still need this.

Comment 5

[Alexandre Poirot [:ochameau]]

The second issue is that, I think that mozbrowser iframe are only enabled on b2g.
This setting dom.mozBrowserFramesEnabled is only set on b2g and enable the whole mozbrowser API: 
http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.js#55

Comment 6

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Eddy would you be interested looking into this ?

Comment 7

[Eddy Bruel [:ejpbruel]]

I have enough on my plate right now.

Since this is labeled as P1, please talk to Dave if you still think this is a priority and I should work on this instead of my other stuff.

Comment 8

[Gabor Krizsanits (INACTIVE)]

(In reply to Irakli Gozilalishvili [:irakli] [:gozala] [@gozala] from comment #1)
> It looks like only thing stopping us from using html frame is that
> swapFrameLoaders is not implemented for them:
> 
> http://dxr.mozilla.org/mozilla-central/content/html/content/src/
> nsGenericHTMLFrameElement.cpp.html#l146
> 
> Fixing that would allow us to use html iframes.

As I mentioned earlier that is not fixing something. This is implementing something very complex. Expect a lot of uncertainties in this project and estimate it as very big task, with a possible negative outcome.

Comment 9

[Gabor Krizsanits (INACTIVE)]

Avoiding using swapFrameLoaders in the SDK however, is a desirable goal imo that owuld solve this problem.

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562