593923 - make hidden window XUL/XHTML/XML on Windows and Linux

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

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

One of the Jetpack SDK API implementations uses the hidden window to load web pages in XUL iframes that enforce type="content".

On Windows and Linux, however, the hidden window is HTML, in which it is not possible to create XUL iframes that enforce type="content", so the implementation has to create an HTML iframe, load a XUL document into it, and then create XUL iframes inside that document.

This hack introduces enough complexity into the implementation to cause subtle bugs that are difficult to debug and fix or work around.  It sure would be handy if the hidden window were of a type that permitted the creation of XUL iframes that enforce type="content" on Windows and Linux in addition to Mac.

Note: that type doesn't have to be XUL; XHTML is sufficient (or, for that matter, any XML type).

Also, ultimately bug 565388 should get fixed, which would make it unnecessary for the Jetpack SDK API to use the hidden window in the first place (which I am aware there are long-standing plans to remove for Windows and Linux over in bug 71895).

Until that happens, however, the hidden window is the best way we can find to implement the API, and it would be behoove us to optimize it for that purpose.

Benjamin & bz: would it be relatively simple to make this change, or do Windows/Linux depend in some way on the hidden window being HTML?

Comment 1

[Boris Zbarsky [:bzbarsky]]

> in which it is not possible to create XUL iframes that enforce type="content"

Why not?  Just creating XUL iframes and putting them in the document should work.  How are you doing it?

Comment 2

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

(In reply to comment #1)
> > in which it is not possible to create XUL iframes that enforce type="content"
> 
> Why not?  Just creating XUL iframes and putting them in the document should
> work.  How are you doing it?

We're calling document.createElementNS(XUL_NS, "iframe"), which throws "(NS_ERROR_NOT_AVAILABLE) [nsIDOMHTMLDocument.createElementNS]", since the hidden window is an HTML document on Windows and Linux.

Comment 3

[Boris Zbarsky [:bzbarsky]]

1253 NS_IMETHODIMP
1254 nsHTMLDocument::CreateElementNS(const nsAString& aNamespaceURI,
1255                                 const nsAString& aQualifiedName,
1256                                 nsIDOMElement** aReturn)
1257 {
1258   return nsDocument::CreateElementNS(aNamespaceURI, aQualifiedName, aReturn);
1259 }

Your problem isn't that it's not HTML but that it's not chrome:// I would think.  Just changing the MIME type won't help.

Comment 4

[Benjamin Smedberg]

The hidden window is about:blank and doesn't have privileges to use XUL. Only changing it to have chrome privileges would help, and I'm loathe to do that at this point in the cycle because I'm not sure what effects it would have.

Why can't you create your own hidden window, instead of piggybacking on the special Firefox one?

Comment 5

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

(In reply to comment #4)
> The hidden window is about:blank and doesn't have privileges to use XUL.

Hmm, it claims to be resource://gre-resources/hiddenWindow.html on my Linux box, although perhaps that's also "not chrome".


> Why can't you create your own hidden window, instead of piggybacking on the
> special Firefox one?

I wasn't aware that was possible from script, as nsIAppShellService::createHiddenWindow is [noscript].  What's the best way to do it?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> although perhaps that's also "not chrome".

Correct.  It's not.

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

Attachment: patch v1

(In reply to Benjamin Smedberg  [:bsmedberg] [away 27-July until 7-Aug] from comment #4)
> The hidden window is about:blank and doesn't have privileges to use XUL.
> Only changing it to have chrome privileges would help, and I'm loathe to do
> that at this point in the cycle because I'm not sure what effects it would
> have.

Can we now reconsider doing this?

It would be really helpful for bug 780123 and the Add-on SDK as myk already pointed out. When I first encountered the hiddenWindow I found it *very* confusing that we only have a privileged hiddenWindow on Mac.

Comment 8

[Benjamin Smedberg]

Comment on attachment 648676 [details] [diff] [review]
patch v1

<bsmedberg> Can we just remove the hidden window?
<Ms2ger> Heh, good luck
<gavin> no
* bsmedberg is staring at the review request for bug 593923
<gavin> well, yes
<bsmedberg> and make each potential create their own global?
<bsmedberg> i.e. separate the mac-default-menu thing from the place-to-stick-stuff thing
<gavin> er, bug 769771 removes most of the motivation for bug 593923 AFAICT
<gavin> all of it, looks like
<gavin> so you can get rid of that request with a WONTFIX, IMO