Last Comment Bug 60338 - gtkEmbed crashes/misbehaves when opening new windows
: gtkEmbed crashes/misbehaves when opening new windows
Status: RESOLVED DUPLICATE of bug 55032
:
Product: Core Graveyard
Classification: Graveyard
Component: Embedding: GTK Widget (show other bugs)
: Trunk
: x86 Linux
: P3 normal with 1 vote (vote)
: ---
Assigned To: Stuart Parmenter
: Stuart Parmenter
:
Mentors:
: 60600 (view as bug list)
Depends on: 60516
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-16 09:10 PST by jblack
Modified: 2012-04-05 00:46 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description jblack 2000-11-16 09:10:46 PST
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 2000-11-19 09:14:32 PST
*** Bug 60600 has been marked as a duplicate of this bug. ***
Comment 2 rusty.lynch 2000-11-19 09:27:48 PST
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 2000-11-19 09:46:39 PST
oh, and i am also confirming the bug...
Comment 4 rusty.lynch 2000-11-21 09:19:07 PST
This root cause for this bug is described in bug #60516. Maybe I should have
just made this a dup?
Comment 5 rusty.lynch 2000-11-27 23:03:08 PST
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 ***

Note You need to log in before you can comment on or make changes to this bug.