281405 - nsIWindowCreator.createChromeWindow - request support for default standalone browser

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: GRE Core, enhancement)

Description

[Christophe Cornu]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: 

The java SWT Browser widget (Eclipse.org) embeds Mozilla on Linux. 
nsIWindowCreate.createChromeWindow is used to embed new windows. This 
interface does not provide a 'free' Mozilla window in case the embedder does 
not wish to provide one (or if I missed it - please let me know!). I 
understand this may sound strange after all the trouble to precisely embed 
Gecko and customize it but here is the use case...

Some users would like to embed Mozilla into an application (say Eclipse) with 
fully integrated HTLM content. This HTML content contains links they want to 
see opened in an external standalone Mozilla browser - with the full Mozilla 
(or Firefox in the future) UI/toolbars/popup menu etc. They don't expect to 
have any further control over these separate instances.

IE provides this through the DWebBrowserEvents2.NewWindow2 notification - if 
the embedder does not pass a new web control, a separate IE is launched. Do 
you think you could add similar capability in the future?

Of course the most common case is that embedders want to retain control over 
the new windows opened as we currently support. But there are cases where they 
actually would prefer let the user have the new window opened in a full 
Mozilla/Firefox experience. Can't blame them for preferring the 'real' thing ;-
)

Thanks for any feedback,
Chris

Reproducible: Always

Steps to Reproduce:

Comment 1

[Benjamin Smedberg]

This is a problem we need to solve for xulrunner also (a generic method of
opening URIs in the default browser). There is currently code in the toolkit
such as:

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/content/extensions.js#97

Which is more than a little bit broken, because non-networking code isn't ever
supposed to instantiate a standardurl like that.

I don't think that nsIWindowCreator* is the right place to hang this functionality.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So.. wouldn't this be handled reasonably by just running the URI through the
URILoader?  That already does things like open helper apps as needed, etc...

Comment 3

[Benjamin Smedberg]

are you ready to freeze the uriloader?

Comment 4

[Boris Zbarsky [:bzbarsky]]

By when?  1.8, probably not (though if it's needed, I think we could be; I would
need to look at the list of issues I had and see whether the relevant api
changes can be made now without destabilizing back end changes).  I was hoping
to have it nicely frozen by 1.9.

Comment 5

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 6

[Benjamin Smedberg]

Mass change of bugs in the "Embedding: GRE Core" component in preparation for archiving it. I believe that these are no longer relevant; but if they are, they should be reopened and moved into a component relevant to the code in question.