nsIWindowCreator.createChromeWindow - request support for default standalone browser

RESOLVED INCOMPLETE

Status

Core Graveyard
Embedding: GRE Core
--
enhancement
RESOLVED INCOMPLETE
14 years ago
2 years ago

People

(Reporter: Christophe Cornu, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
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

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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

14 years ago
are you ready to freeze the uriloader?
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

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
QA Contact: gre

Comment 6

2 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.