Webclient (PR3) core dumps when trying to Navigate links on Solaris



Core Graveyard
Java APIs to WebShell
17 years ago
5 years ago


(Reporter: Ashu Kulkarni, Assigned: Ashu Kulkarni)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
When Webclient is run on Solaris and one tries to navigate links, Mozilla
seg-faults in nsWindow.cpp due to null-ptr dereference.

This is because in Webclient, the top level Window wrapping the WebBrowser
object is not a gtk window, but rather, a motif window (Java native peer). In
mozilla/widget/src/gtk/nsWindow.cpp::SetFocus, when the code tries to get a
nsWindow from the GtkWidget, a null is returned. When this is dereferenced,
without checking whether nsWindow is null, a seg fault occurs.

The fix for this, is to check if the nsWindow returned by the
gtk_object_get_data(GTK_OBJECT(top_mozarea), "nsWindow");
call is null.

The cvs diff -u for the fix is as follows -

Index: nsWindow.cpp
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.305
diff -u -r1.305 nsWindow.cpp
--- nsWindow.cpp        2000/09/22 06:48:56     1.305
+++ nsWindow.cpp        2000/10/23 16:30:46
@@ -1085,15 +1085,17 @@
     if (!GTK_WIDGET_HAS_FOCUS(top_mozarea))
       nsWindow *mozAreaWindow = (nsWindow
*)gtk_object_get_data(GTK_OBJECT(top_mozarea), "nsWindow");
-      mozAreaWindow->mBlockMozAreaFocusIn = PR_TRUE;
+      if (mozAreaWindow) {
+        mozAreaWindow->mBlockMozAreaFocusIn = PR_TRUE;
-      printf("mozarea grabbing focus!\n");
+        printf("mozarea grabbing focus!\n");
-      gtk_widget_grab_focus(top_mozarea);
-      // this will show the window if it's minimized and bring it to
-      // the front of the stacking order.
-      GetAttention();
-      mozAreaWindow->mBlockMozAreaFocusIn = PR_FALSE;
+        gtk_widget_grab_focus(top_mozarea);
+        // this will show the window if it's minimized and bring it to
+        // the front of the stacking order.
+        GetAttention();
+        mozAreaWindow->mBlockMozAreaFocusIn = PR_FALSE;
+      }

Since in the normal browser operation, the GtkWidget is an actual gtk window,
the call to gtk_object_get_data never returns a null. 

This fix is required to get Webclient working with Mozilla PR3 codebase.


Comment 1

17 years ago
I filed, I accept.



17 years ago
Blocks: 52883

Comment 2

17 years ago
Looks good to me r=edburns.  Let's get r=blizzard and sr= someone and get this
into the trunk.
Are you guys creating the mozarea object and passing it in as the parent as part
of the Create() call?  I do something similar in the embedding widget and I
never get crashes where you do.

Comment 4

17 years ago

We are creating the MozArea and passing it to the Create call just as you are in
yout gtkembed example. Check out
in lxr.

The reason our MozArea is diff from yours is that our top level window is a
native motif window (what Java uses as its native peers) while yours is a gtk

Acutally, in the gtk embedding example I pass in a standard GtkContainer, not a
mozarea as the parent of the top mozilla window.  The mozarea object is created
and managed by mozilla.  Have a look at:


To be honest, I'm not sure what the effect of having a mozarea object that's not
managed by mozilla will be.  I would expect other bugs to crop up.  Would you be
willing to pass in a GtkContainer instead of creating the mozarea yourself?

Comment 6

17 years ago
Take a look at
to see how I create the GtkWidget and mozArea. What is returned in this function
is passed to the BaseWindow->Create call in

I tried passing the top level GtkContainer, but nothing was being displayed, not
even the Java Window.

Only if I create the MozArea myself and pass it in like I do here, does the
embedded Browser come up.

Comment 7

17 years ago
Blizzard: please read and comment.
Keywords: patch
You really want to create something like a GtkBin class and pass that into the
CreateNative() call.  If you look at the CreateNative() all in nsWindow.cpp


you can see that it looks to see if the parent is a GtkContainerClass or child
thereof.  If it is, then it will create the mozArea which is really what you
want.  Just make sure that the widget that you pass in is realized first.

Comment 9

17 years ago
I create a mozArea, and pass it's SuperWin to the Create call. In
nsWindow::CreateNative, it checks to see if the widget is a SuperWin and handles
it correctly.

Look at http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#1718

From looking at nsWindow.cpp, this seems to be a valid approach. If I just
create a GtkContainer and pass it to the Create call, nothing gets drawn and it
does not complain about the widget not being realised first (I suppose Gtk would
complain if the Widget hadn't been realised).
The code supports that because that's how the native child windows are created.
 However, the code doesn't deal with the case where the mozarea widget that is
passed was not created by the mozilla code itself, like you are doing.

Are you passing in a GtkContainer or a GtkBin?  The GtkContainer is a base class
that doesn't have a lot of functionality on its own.  The GtkBin class is a
container that holds exactly one child which is what you want.

Comment 11

17 years ago
Created attachment 18511 [details] [diff] [review]
cvs diff -u of MotifBrowserControlCanvas.cpp and NativeEventThread.cpp

Comment 12

17 years ago
Creating a GtkBin object and passing it to BaseWindow->Init fixed the problem.
The patch for Webclient is attached. With this fix no changes are needed in the
mozilla code.

thanks for your help in this Chris!



17 years ago
Blocks: 49126

Comment 13

17 years ago

Pls verify fix so I can close this Bug.


Comment 14

17 years ago
Created attachment 18514 [details]
tar of modified files. untar in java/webclient

Comment 15

17 years ago
Patch modifies


Comment 16

17 years ago
The fix is not checked in, correct?

Comment 17

17 years ago
it's not checked in. I'm waiting for r=a=edburns


Comment 18

17 years ago
This looks good.  r=a=edburns.  Just remove the printfs.

Comment 19

17 years ago
Fix checked in. Closing this Bug.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 20

16 years ago
Work now. Mark VERIFIED
Component: Java APIs to WebShell → Java APIs to WebShell
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.