60338 - gtkEmbed crashes/misbehaves when opening new windows

Status: RESOLVED DUPLICATE of bug 55032

(Core Graveyard :: Embedding: GTK Widget, defect, P3)

Description

[jblack]

I've been trying to use the GtkMozEmbed widget, and have been
having problems handling new browser windows, both from
HTML and from Javascript.  My problem can be reproduced by
pointing gtkEmbed at the following URL:

  http://users.ids.net/~jblack/popups.html

The above page tries to do a window.open() from Javascript.  The
version of gtkEmbed in the Nov. 15 nightly seems to do the
window.open(), but it doesn't display any content in either the
original window or the new one.  It's supposed to display a link
in the original window that opens a new browser window via
a target="_blank" attribute in the <a> reference.  The
link doesn't even appear..

In the  next URL, I've taken out the Javascript, and left in
the <a href=...  target="_blank">:

  http://users.ids.net/~jblack/popups1.html

Here, the HTML link appears, but when clicked it popups a
new empty window.

In both cases, the gtkEmbed app usually crashes shortly after
hitting either of the above links.  I've been seeing this
behavior since M18 -- I haven't checked back further than that.
It doesn't seem to matter whether I do the build myself or
pull down binaries from mozilla.org.

I also tried this on a couple of other GtkMozEmbed widget-based
programs:

The TestGtkMozEmbed program loads the first URL mentioned above,
and correctly does the window.open().  But when the link in
the original window is clicked it loads the new
content in the original window instead of in a new
window (as I'd expect with a "_blank" or "_new" target).
At this point, the "Back" functionality (stack?) seems
to have been reset -- you can't get back to the
earlier content.

"Galeon" seems to be somewhere between gtkEmbed and
TestGtkMozEmbed with the above URLs; it crashes trying to
handle the Javascript popup, and loads the target="_blank" link
into the orignal browser window.

I thought that Bug 59823 might be related to what I'm seeing.
However, I wasn't clear when I read Bug 59823 on whether the
"1 window" limit was associated with the GtkMozEmbed widget, or
a limitation of the sample programs that use it.  It also wasn't
clear whether the patch attached to 59823 was intended to simply
prevent crashing to provide a broader fix.

Comment 1

[rusty.lynch]

*** Bug 60600 has been marked as a duplicate of this bug. ***

Comment 2

[rusty.lynch]

We seem to have a cluster of embed bugs that are related (and maybe even the
same bug.)

This bug and duplicate bug #60600 both talk about any url load with "_blank" or
"_new" set as the target.  Also, bug #60516 refers to secondary window targets
being dropped so that any new uri load request with a named target (other then
"_blank" and "_new") will cause a new window to be opened even if the targeted
window is already open.

I've also seen (but havn't logged in bugzilla since I'm having a hard time
reproducing the bug) where complex framesets that use JavaScript to call on
functions in other window targets seem to get confused and break the page (but
only in the embedded version of Mozilla.)

And then there is bug #60522 that talks about embedded Mozilla having problems
with JavaScript: urls that open new windows. I'm not so sure that this is
related, but since it involves opening new targets (and only in the embedded
browser) it makes me suspicious.

Comment 3

[rusty.lynch]

oh, and i am also confirming the bug...

Comment 4

[rusty.lynch]

This root cause for this bug is described in bug #60516. Maybe I should have
just made this a dup?

Comment 5

[rusty.lynch]

Ok, looks like I was wrong with my last comment.  The real bug is #55032 which
is rooted in an Oct 1 checkin to nsThread.cpp/nsThread.h

The other bug report is where all the work is being done so I'm going to go
ahead and mark this a duplicate.


*** This bug has been marked as a duplicate of 55032 ***