188055 - [ActiveX] Target=_blank fails to work in ActiveX control, as well as javascript window.open()

Status: RESOLVED FIXED

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

Description

[Aaron Graves]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

When clicking a link like <a href="http://www.mozilla.org" target=_blank>, the
ActiveX control will fire the NewWindow event, but nothing will be displayed in
the new window. It works fine, however if you right-click the link to bring up
the context menu, and select "Open in new window". Also, the JavaScript
window.open() appears not to work also. To test this, visit any webpage that
will bring up a pop-up window (http://www.netscape.com is notorious for this).
Ask if you need more details.

Reproducible: Always

Steps to Reproduce:
1. Drop the ActiveX into, say a VB program.
2. Write code to handle the NewWindow2 event. Something like this:
   Private Sub mb_NewWindow2(ppDisp As Object, Cancel As Boolean)
   Dim tt As New frmBrowser
   Set tt = New frmBrowser
   tt.Show
   Set ppDisp = tt.mb.Object
   End Sub
3. Navigate in the browser you just created to http://www.netscape.com or any
other site with pop-up ads. Observe as the windows pop up, all that is in the
browser ActiveX component is whitespace.
Actual Results:  
An empty browser object instead of the popup window

Expected Results:  
Loaded the content of the pop-up into the new browser window created.

Comment 1

[Zook Valem]

Try 'new' instead of '_blank'.

--clip--

<a href="http://www.mozilla.org" target="new">

--clip--

Comment 2

[Aaron Graves]

It's not about what I use, it's about what big-time websites (like Netscape's
and Microsoft's) use. They insist on using target=_blank, so the ActiveX control
should be able to handle that request.

Comment 3

[Adam Lock]

Attachment: Patch

Issue turned out to be simple. Somewhere along the line, the window watcher now
requires the window chrome to be able to return an nsIDOMWindow. I've added
this code and all seems well again.

Comment 4

[Adam Lock]

Comment on attachment 118660 [details] [diff] [review]
Patch

Dan & Chris, can I have a r/sr on this simple patch to return nsIDOMWindow in
the ActiveX controls chrome implementation of nsIInterfaceRequestor? This
allows popup windows to open and navigate properly.

Patch also contains 1-line change to use size_t instead of an int for a string
length operation.

Thanks

Comment 5

[Dan M]

Comment on attachment 118660 [details] [diff] [review]
Patch

WindowCreator's nsIDOMWindow requirement isn't new, but there is a fallback: it
asks the new chrome for an nsIDocShellTreeItem if it can't find an
nsIDOMWindow. Perhaps the fallback stopped working. Anyway, seems good. r=danm.

Comment 6

[Christopher Blizzard (:blizzard)]

Comment on attachment 118660 [details] [diff] [review]
Patch

sr=blizzard

Comment 7

[Adam Lock]

Comment on attachment 118660 [details] [diff] [review]
Patch

Requesting 1.4a approval if there is still time. Small patch fixes obvious
bustage in the control

Comment 8

[Asa Dotzler [:asa]]

Comment on attachment 118660 [details] [diff] [review]
Patch

please land this change first thing in 1.4beta. thanks.

Comment 9

[Adam Lock]

Fix is checked in