Closed
Bug 281405
Opened 20 years ago
Closed 8 years ago
nsIWindowCreator.createChromeWindow - request support for default standalone browser
Categories
(Core Graveyard :: Embedding: GRE Core, enhancement)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: christophe_cornu, Unassigned)
Details
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•20 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
Comment 2•20 years ago
|
||
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•20 years ago
|
||
are you ready to freeze the uriloader?
Comment 4•20 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: gre
Comment 6•8 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
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•