gtkEmbed crashes/misbehaves when opening new windows



18 years ago
7 years ago


(Reporter: jblack, Assigned: pavlov)



Firefox Tracking Flags

(Not tracked)




18 years ago
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:

The above page tries to do a from Javascript.  The
version of gtkEmbed in the Nov. 15 nightly seems to do the, 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">:

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

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

The TestGtkMozEmbed program loads the first URL mentioned above,
and correctly does the  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

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

Comment 2

18 years ago
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

18 years ago
oh, and i am also confirming the bug...
Ever confirmed: true

Comment 4

18 years ago
This root cause for this bug is described in bug #60516. Maybe I should have
just made this a dup?
Depends on: 60516


18 years ago
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 5

18 years ago
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 ***
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.