Alessio Placitelli [:Dexter] Reporter
	Description • 10 years ago

In bug 1111022 I tried to use |createWindowlessBrowser| (introduced in bug 846906), which needs content -> chrome messaging to access the UITour API.

Even though I'm able to open a page within the browser, I couldn't find a way to get get messages pass from content to chrome, regardless of the argument value (|true| to create a Chrome browser).

We get two different behaviours:

- using a "chrome" type browser (argument to |true|): we can get a messageManager, can load a frame script, but no message get caught by the content script.
- using a "content" type browser (argument to |false|): we can't get a messageManager (not directly nor indirectly from other interfaces).

Moreover, when attaching an IFRAME to a Browser of the "chrome" type, no "load" event gets fired/caught on the latter.

It might be interesting to note that "chromeEventHandler" is null, while this has a meaningful value when creating normal tabs.

Another attempt to use this function was in bug 859672.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 1 • 10 years ago

(In reply to Alessio Placitelli [:Dexter] from comment #0)
> - using a "chrome" type browser (argument to |true|):
Sorry, which argument, where?
Do you have some minimal example code?


(I know nothing about Bug 846906)

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 2 • 10 years ago

(based on IRC, this sounds like some kind of misunderstanding about message managers)

	Tim Taubert [:ttaubert] (inactive)
	Comment 3 • 10 years ago

Alessio and I spent the day on trying to make it work with Olli's suggestions. We got as far as using the following URL to load in the nsIWebNavigation object returned by createWindowlessBrowser():

data:application/vnd.mozilla.xul+xml;charset=utf-8,<window xmlns='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'><browser nodefaultsrc='true' type='content-primary'/></window>

That seems to work fine and the progress listener signals a successful load. Retrieving the <browser> from the document works and we can load frame scripts that are executed.

Calling browser.loadURI("data,text/html,foo") does unfortunately not work. We're always failing with NS_ERROR_DOM_INVALID_STATE_ERR here:

http://hg.mozilla.org/mozilla-central/annotate/34e2d2bd7ec4/parser/html/nsHtml5StreamParser.cpp#l904

The cause of this seems to be that nsDocShell::EnsureScriptEnvironment() fails here:

http://hg.mozilla.org/mozilla-central/annotate/34e2d2bd7ec4/docshell/base/nsDocShell.cpp#l12586

nsDocShell::mTreeOwner should probably not be null? I added some debug statements and it's indeed a nullptr. I have no clue of docShell tree owners but they seem to be not-null for normal <browser>s in a default browser window.

Does the "windowless browser" somehow cause mTreeOwner to be null? Should it be not-null? Should the code be able to deal with mTreeOwner=nullptr?

	Alessio Placitelli [:Dexter] Reporter
	Comment 4 • 10 years ago

As a side note, using a privileged browser (|type='chrome'|) presents us with a different behaviour: the page loads correctly and no error is reported.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 10 years ago

Ah, sounds like we're effectively missing one tree owner. We have only the owner for either chrome or content docshells, not both.
In normal cases when a content docshell is loaded, we end up here
http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsXULWindow.cpp#1570
called from
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFrameLoader.cpp#690

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 6 • 10 years ago

In normal cases we use 
http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsChromeTreeOwner.h#23
or 
http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsContentTreeOwner.h#25

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 10 years ago

And when adding content docshell to be a child of a chrome docshell, 
content docshell gets just null treeowner by default
http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp?rev=a629bc251c81&mark=4047-4049,4074-4076,4078-4078#4025


So, in other words, windowless browser supports either chrome or content, but not both, and
frame message managers are for chrome <-> content (except the one for mozbrowser, which is rather special case for content<->content, but can't be accessed from content).

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 10 years ago

Windowless browser is for creating the equivalent of a <browser> but without a window.  It's not meant for creating an entire web browser UI....

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 10 years ago

Right, but here use of message manager is apparently wanted, and we have frame message manager
(that thing which has the child side which can execute scripts) only for xul:browsers/iframes, 
so one would need to have a chrome document where those live, and then, I guess, a content window
under them.

If use of chrome everywhere is ok, <xul:browser type="chrome" forcemessagemanager="true"> should work.

	Benjamin Smedberg
	Comment 10 • 10 years ago

This browser is loading web content and should be a content-type docshell.

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 10 years ago

OK, so the options are either to make message managers not tied to a <xul:browser> so we can have one attached to the windowless browser or to scope-creep windowless browser stuff to support both treeowners...

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 12 • 10 years ago

I think the latter is less work. The treeowner for content docshells could be rather dummy.