142904 - [ActiveX] NewWindow2 event handler doesn't properly create a new window

Status: RESOLVED INVALID

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Scott MacGregor]

I'm using a product based on the winamp3 beta. Winamp3 allows you to use mozilla
instead of IE via Adam's activeX control. 

When I click on a link which requires a new window, we are unable to bring up
that new window. Here's why....

Before we can create a new window, we fire a NewWindow2 event as specified in
DWebBrowserEvents2 over in: CWindowCreator::CreateChromeWindow

We are insisting that the embedder (sp?) help us out by providing an interface
to a container object which should be used as the new window. If we don't get
such an interface back, then we are failing to create the window. According to
MS design documents at
http://msdn.microsoft.com/workshop/browser/webbrowser/reference/ifaces/dwebbrowserevents2/newwindow2.asp

the application processing the event does not have to return an interface for a
webbrowser. In that case, we should create a new Internet Explorer object and
load the url in that. Obviously we don't want to do that. If the mozilla browser
chrome is installed on the system, we'd ideally like to bring up a mozilla
browser window. 

Attaching an ad hoc patch that is NOT intended to be checked in to demonstrate
what such a fix might look like.

Comment 1

[Scott MacGregor]

Attachment: example patch (not something to be checked in)

Okay this patch shows how we could tap into the appshell service to create a
new window in CWindowCreator::CreateChromeWindow if the handler of our
NewWindow2 event chooses to not return a web browser. 

This is not intended to be checked, but is only an example (although it does
work).	However, it adds a new and probably extremely undesireable dependency
of embedding on the xpfe appshell service.

Comment 2

[Scott MacGregor]

re-assigning to me since I'm trying to play around with this. cc'ing Adam in
case he has any input or suggestions. 

The example patch introduces a dependency we probably don't want and it only
brings up a chromeless browser window to display the content in a new window.
According to the specs at msdn, we really want to be creating an internet
explorer type object. That to me, means a full fledged browser object. 

I tried to hack creation of some xul browser chrome from
CWindowCreator::CreateChromeWindow just to see what would happen. Unfortunately,
I *think* it's going to be quite hard to have a new mozilla browser window come
up in full chrome while still having it be a part of the same process space as
the app using us. I'm not really familiar with the event model when we are
invoked as an activeX control but I'm pretty sure we aren't spinning up
mozilla.exe and pumping events through nsAppShell::Run() like we do when you run
a stand alone browser. Most of the code I tried to get a browser window to come
up within this process space failed because events weren't getting pumped properly. 

Finally, we'd have to do this in a dynamic manner. Gecko may be the only
component installed on the machine. We may not have a full fledged mozilla
browser we can bring up. The code in the activeX code shouldn't depend on any
core mozilla browser apps code. Maybe it's just some code to check with the
component manager to see if we have a service which can load browser chrome. If
the service is there, fire up a new browser window. If just gecko is
installed...fall back to some sort of chromeless window. 

Comment 3

[Adam Lock]

Probably related/partial dupe of bug 122107

Comment 4

[Glenn MacGregor]

I see this problem with the latest 1.0.0 build on win2000, using the component 
through Borland C++Builder 5.  I haven't investigated too much on this one.  
Are you tossing around some ideas on how to fix it?  Is there an estimated time 
on this bug?

Comment 5

[Glenn MacGregor]

Even with Mozilla 1.0 (BuildID 2002053012) installed the new window will not 
come up.  Can I catch that event in my app or is it further down?  If I can 
catch it myself I could open another copy of my browser.

Comment 6

[Adam Lock]

I don't think that launching Mozilla would help since it does not implement
IWebBrowser/2/App making it essentially useless to bother launching it.

The best solution would be if Mozilla the app implements these interfaces in a
COM object and registers itself in the registry. Then it should be possible to
CoCreate an instance of this object, which causes the Mozilla app to launch from
that it can be automated it via the IWebBrowserApp interface.

The previous patch would launch Mozilla in-process (with WinAmp!) which is not
something that is desirable, likely to work or viable if the control is part of
a Mozilla runtime environment or other subset of Mozilla. 

Comment 7

[irongut]

If we don't want the new window to be in the process space of the calling app,
why not just pass the URL on to the OS and get it to open it in the default browser?

Comment 8

[Adam Lock]

Because the default browser might not implement IWebBrowser as previously explained.

The choices boil down to:

1. Implement a mini-browser in the control which pops up when the app doesn't
return its own window.
2. Launch IE and return the IWebBrowser from that
3. Implement IWebBrowser on Mozilla.

Number 3 is unlikely to happen any time soon which leaves the other two choices.
I'd lean towards implementing a mini-browser in the control but that is
obviously a lot of work. The workaround for the time being is for the client to
return its own window.

Comment 9

[Jacob Floyd]

In Win XP SP2 MS has impelemented another event NewWindow3.
http://msdn.microsoft.com/workshop/browser/webbrowser/reference/events/newwindow3.asp?frame=true
This contains the URL that is being browsed to and so could be used to bypass
this problem. If this were implemented in the ActiveX control we wouldn't need
to play with newwindow2 and instead pass the information to whatever event
handler function the app (be it winamp or something else) implements.
I can't write a patch to add this right now, but I can add a feature request.
I'll do that and add a link in another comment to it.

Comment 10

[Jacob Floyd]

Created Bug 279300 to request NewWindow3

Comment 11

[Ed Morley [:emorley]]

The ActiveX embedding API was removed in bug 662023 and friends, making this INVALID.

[Filter bugspam on activexinvalid]