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:
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...
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.
mass reassigning to nobody.
Assignee: dougt → nobody
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.