Closed Bug 57046 Opened 24 years ago Closed 24 years ago

Applets crash mozilla

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
All
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: edburns, Assigned: joe.chou)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [rtm need info]) 

Using mozilla RTM branch from 10/16/00 and Java Plugin from 10/13/00, applets
crash the browser.
added cc
I see this with my build.
Status: NEW → ASSIGNED
Keywords: crash
Priority: P3 → P1
On 16 October 22:20:14, Jim Melvin - Java Software Engineering wrote:
> Some additional data....
> 
> We also crash using our PR3 Java Plug-in.  This must have been broken
> after Oct 7, as we have a build of mozilla from that day and it works.
> 
> Hope this helps to narrow it down.
> 

On 16 October 15:04:57, Steven Katz - Sun Microsystems wrote:
> We pulled down the latest source this morning and the plugin now
> segfaults in code that we have not changed (in fact the same plugin
> works with a version of Mozilla built last friday).

> It looks like the problem has to do with a structure, Mozilla is
> handing us, that hold information regarding the gtk.native windows.

> Here is the stack trace (abridged):
> 
> 
> 
> #0  0xfcd24684 in JavaPluginInstance5::SetWindow (this=0x6c7140, win=0x6d8478)
>     at ../../oji-plugin/src/motif/navig5/JavaPluginInstance5.cpp:431
> #1  0xfcf385b0 in nsPluginHostImpl::InstantiateEmbededPlugin ()
>    from 
>
/net/altair.east/terra/space2/plugin/mozilla.latest/solaris/sparc/mozilla/dist/bin/components/libgkplugin.so
> #2  0xfbb55630 in nsObjectFrame::InstantiatePlugin ()
>    from 
>
/net/altair.east/terra/space2/plugin/mozilla.latest/solaris/sparc/mozilla/dist/bin/components/libgklayout.so
> 
> 
> win is: (nsPluginWIndow *)
> (gdb) p *win
> $7 = {window = 0x54002cf, x = 8, y = 8, width = 300, height = 300, clipRect =
{top = 0, left = 0, bottom = 300, 
>     right = 300}, ws_info = 0x0, type = nsPluginWindowType_Window}
> 
> the value of window seems to be what is out of wack:
>          GdkSuperWin * superWin = (GdkSuperWin *) win->window;
> 425         // End Added by Mark
> 426         Window parentWindowID;
> 427         Window rootWindowID;
> 428         Window * childrenWindowIDs;
> 429         unsigned int numberOfChildren;
> 430         //int containerWindowID =
GDK_WINDOW_XWINDOW(containerWidget->window);
> 431         int containerWindowID =
GDK_WINDOW_XWINDOW(superWin->shell_window);
> 
> 
> (gdb) p superWin->shell_window
> Cannot access memory at address 0x54002df
> 
> 
> Anyone know what might have changed in Mozilla over the weekend?
> 
> Any ideas about who to talk to to track this down?

This looks like the change that pav made to the what
nsIWidget::GetNativeData(NS_NATIVE_PLUGIN_PORT) returns on Unix.  It used to be
that it returned the superwin structure but we set it up so that it returns the
native X id of the inner window.

This means embedders don't have to know anything about the superwin structure.
Just treat the contents of window->window as a native X id.  Have a look at this
bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=45162

The patch has an example.
Adding CC ekrock
Steve Katz:

Is this enough information for you to fix it?
Is this bug Solaris-specific or is it xp? If it's xp, it qualifies for Netscape 
PDT rtm++ status. Please nominate rtm to put this on Netscape 6 RTM radar if 
it's xp.
duplicate of bug 56560? if so, this is xp -- that's a Linux bug.
*** Bug 56560 has been marked as a duplicate of this bug. ***
This impacts all Unix Java Plugin users.  It also impacts all NS6.0 Plugin API
users on unix.
Whiteboard: [rtm+]
On 17 October 18:29:40, Steven Katz - Sun Microsystems wrote:
> You asked:
> 
> Steve Katz:
> 
> Is this enough information for you to fix it?
> 
> ------
> 
> It should have been, but when I tried a test to see if this fixes it, the 
> behavior is not what I expect.
> 
> The browser no longer crashes, but the applet does not display either.  What I 
> see is the window briefly appear and then disappear.  The applet is actually 
> running (it says "Applet Started" in the status window and side effect [like 
> bringing up other windows] occur).
> 
> Where does the window that they are passing us live in the hierarchy?  
> 
> What I need is a reference to the same window I would have gotten doing what
we 
> did prior to the change:
> 
> here is what the code use to do:
> 
>     GdkSuperWin * superWin = (GdkSuperWin *) win->window;
>     Window parentWindowID;
>     Window rootWindowID;
>     Window * childrenWindowIDs;
>     unsigned int numberOfChildren;
>     int containerWindowID = GDK_WINDOW_XWINDOW(superWin->shell_window);
> 
>     XQueryTree(GDK_DISPLAY(), containerWindowID,
>                                &rootWindowID, &parentWindowID,
>                                &childrenWindowIDs, & numberOfChildren);
> 
>     if (numberOfChildren >= 1) {
>         containerWindowID = childrenWindowIDs[0];
>     }
> 
> Passing what we ended up with from the above to the AppletPanel for
reparenting 
> work.
> 
> What I changed it to was:
> 
>     Window parentWindowID;
>     Window rootWindowID;
>     Window * childrenWindowIDs;
>     unsigned int numberOfChildren;
>     int containerWindowID = win->window;
> 
>     XQueryTree(GDK_DISPLAY(), containerWindowID,
>                                &rootWindowID, &parentWindowID,
>                                &childrenWindowIDs, & numberOfChildren);
> 
>     if (numberOfChildren >= 1) {
>         containerWindowID = childrenWindowIDs[0];
>     }
>     
> This code results in the applet display not showing up.  If I comment out the 
> XQueryTree and if statment at the end then the applet displays, but in a
window 
> NOT contained in the browser (it shows up in a top level window).
> 
> Any ideas?
> 
> stevek
> 
> 

Adding Chris Blizzard to CC.
OK, first of all, you shouldn't need that XQueryTree in there at all.  We are
returning the X window ID of the internal scrolling window.  This window should
be the direct parent of your plugin's applet window.  So your code should look
something like this:

Window containerWindowID = (Window)win->window;

That's it.  If you're getting a new toplevel window then you've set your
container window to the root window which is obviously not what you want. :)

My first impulse would be to stick a printf in widget/src/gtk/nsWindow.cpp in
GetNativeData() in the part of the switch that says something like:

else if (aDataType == NS_NATIVE_PLUGIN_PORT) {
  if (mSuperWin) {
  GdkWindowPrivate *private_window = (GdkWindowPrivate *)mSuperWin->bin_window;
  if (private_window->destroyed == PR_TRUE) {
    printf("PLUGIN WINDOW HAS BEEN DESTROYED\n");
    return NULL;
  }
}
printf("RETURNING %p FOR PLUGIN WINDOW\n", (void
*)GDK_WINDOW_XWINDOW(mSuperWin->bin_window));
return (void *)GDK_WINDOW_XWINDOW(mSuperWin->bin_window);

and put something in your code that checks the value and make sure that it's
getting to you undisturbed or if at all.

Changing Platform and OS for this bug, in an ill-informed attempt to indicate 
this is an XP bug.  There's no way to say "This is an All-Unix-Ports bug" in 
Bugzilla, and I think the best way to get Netscape's attention is to classify 
this as Linux.  So, that's what I've done.  It's not precise, but it's as close 
as I know how to get.
OS: Solaris → Linux
Hardware: Sun → All
Adding rtm keyword to put on rtm radar. Hitting a page with an applet is now 
crashing N6 on Linux. This is a stop-ship bug. (In fact, if we don't get 
this fixed in time for RTM, we might have to pull the Linux JVM from the 
first release. Trying to support Java on Linux doesn't help anyone if we 
wind up crashing the browser in the process! ;-> ) 

Changing [rtm+] to [rtm need info] to conform to PDT usage scheme. (While you're 
still developing the patch, it should be marked [rtm need info]; once you've got 
r= and a=, mark rtm+; then PDT will review and hopefully mark rtm++ to permit 
check-in to the branch.)
Keywords: rtm
Whiteboard: [rtm+] → [rtm need info]
With respects to the problem I mentioned previously. [Applet displays outside of
browser window with new XID passed].  This is happening because
XReparentWindow() is failing.  XReparentWindow() fails because it doesn't like
what it is being given as the parent (the value we are passed via SetWindow()).

What seems to be happening is some kind of race condition between our getting
the value and the X Server getting/dealing with it.

I was able to work around this problem on the plugin side by calling XSync() in
the implementation of SetWindow().

I think this call to XSync() should really happen in the browser though, before
we get passed the XID, since it is reasonable for plugin writers to expect to
get usable, full instantiated, values and objects from the browser. 
That sounds completely reasonable.

added CC
I should note that the XSync() call mentioned above is NOT in the
final build of the Java Plug-in.  Please fix this in the browser!
Otherwise, applets on some systems will appear in a separate, top-level
window.  This appears to happen on slower Unix systems, but we are
basing this on a small data set.  Again, please fix this in the browser
with the XSync() one liner so all NS6.0 plugins will not have to.

James, that's what I meant.  I was hoping that you would be nice enough to give
us a patch to put the XSync() in the right place that works for you.  Maybe we
want to do it before we return the native XID from GetNativeData() in the case
it is asking for the NS_NATIVE_PLUGIN_PORT?  That would catch all cases.

James it can happen on almost all network displays I can test, especially on
Linux display and Solaris box. And XSync in plugin code adds GTK depnedency.
So who is going to put this one line (Xsync()) change in? Should the owner of
the code do that?
Nickolay, how does and XSync() in the plugin code add a GTK dependency?  It adds
an X dependency, but I think we are already dependent on that (since we are
being given an XID).


Steve. easily. First argument of XSync() is Display*, and we need GDK_DISPLAY().
BTW who will create patch for this XSync() in Mozilla? If help needed - I can
try to help.
It sounds like the one line change (adding call of Xsync()) is going to be in
the place where the fix of Bug 45162 was. Would it be better if Pavlov can take
a look at the proposed change, and see if there is any potential problems?
Nickolay, the OJI interface provides us with a way to get the Display * without
going through GTK:

nsIPluginManager::GetValue(nsPluginManagerVariable_XDisplay, &display);


Here's the patch.  No Gtk dependency in the plugin code or your oji plugin.

Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.307
diff -u -r1.307 nsWindow.cpp
--- nsWindow.cpp        2000/10/13 01:10:17     1.307
+++ nsWindow.cpp        2000/10/19 20:10:23
@@ -1940,6 +1940,10 @@
         return NULL;
       }
     }
+    // we have to flush the X queue here so that any plugins that
+    // might be running on seperate X connections will be able to use
+    // this window in case it was just created
+    XSync(GDK_DISPLAY(), False);
     return (void *)GDK_WINDOW_XWINDOW(mSuperWin->bin_window);
   }


Fine. This fix is OK for me. Steve - thanks for info. 
Nikolay, does it fix the problem you mentioned in the other bug with the Sun ->
Linux display?

Yes, thank you. But I can't respond for Java plugin team as it works for my
in-process version of Java plugin. I seems XFree86 does more caching then Xsun
and it wasn't endianness problem.

OK, I'm looking for review then.  Pav, can you just look at that?  It's a quick
on liner and why we need it is well described in this bug.
I don't think this fixes the problem. At least, it doesn't for me. (I
was the one who reported 56560, which later got marked as a dup of this
bug).

I've tried this with current CVS sources from yestarday and today, and
I still get the same result:  The browser segfaults as soon as it tries
to load the Java VM.  I _am_ using the XSync() one-liner patch below.

Here's a trace from my latest attempt.  See 56560 for my original
report.

----- SNIP -----
initilizing the java plugin instantance

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
0x40a99d2a in JavaPluginInstance5::SetWindow ()
   from
/home/spheara/stevek/src/mozilla/dist/bin/plugins/java2/plugin/i386/libjavaplugin_oji.so
(gdb) bt
#0  0x40a99d2a in JavaPluginInstance5::SetWindow ()
   from
/home/spheara/stevek/src/mozilla/dist/bin/plugins/java2/plugin/i386/libjavaplugin_oji.so
#1  0x409f7111 in nsPluginHostImpl::InstantiateEmbededPlugin ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgkplugin.so
#2  0x40cf1281 in nsObjectFrame::InstantiatePlugin ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#3  0x40cf04c6 in nsObjectFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#4  0x40cebf0b in nsLineLayout::ReflowFrame ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#5  0x40cc6891 in nsBlockFrame::ReflowInlineFrame ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#6  0x40cc66da in nsBlockFrame::DoReflowInlineFrames ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#7  0x40cc653f in nsBlockFrame::DoReflowInlineFramesAuto ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#8  0x40cc63e1 in nsBlockFrame::ReflowInlineFrames ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#9  0x40cc5093 in nsBlockFrame::ReflowLine ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#10 0x40cc495a in nsBlockFrame::ReflowDirtyLines ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#11 0x40cc34e1 in nsBlockFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#12 0x40ccad65 in nsBlockReflowContext::DoReflowBlock ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#13 0x40cca83c in nsBlockReflowContext::ReflowBlock ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#14 0x40cc5e50 in nsBlockFrame::ReflowBlockFrame ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#15 0x40cc4d50 in nsBlockFrame::ReflowLine ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#16 0x40cc495a in nsBlockFrame::ReflowDirtyLines ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#17 0x40cc34e1 in nsBlockFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#18 0x40ccdc3f in nsContainerFrame::ReflowChild ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#19 0x40cdd6d8 in CanvasFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#20 0x40ebc31e in nsBoxToBlockAdaptor::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#21 0x40ebbc7b in nsBoxToBlockAdaptor::DoLayout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#22 0x40eb979c in nsBox::Layout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#23 0x40ea62a9 in nsScrollBoxFrame::DoLayout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#24 0x40eb979c in nsBox::Layout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#25 0x40ebdc43 in nsContainerBox::LayoutChildAt ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#26 0x40d11742 in nsGfxScrollFrameInner::LayoutBox ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#27 0x40d1195d in nsGfxScrollFrameInner::Layout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#28 0x40d11791 in nsGfxScrollFrame::DoLayout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#29 0x40eb979c in nsBox::Layout ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#30 0x40ec927c in nsBoxFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#31 0x40d10d98 in nsGfxScrollFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#32 0x40ccdc3f in nsContainerFrame::ReflowChild ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#33 0x40d0f605 in ViewportFrame::Reflow ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#34 0x40cdecd1 in nsHTMLReflowCommand::Dispatch ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#35 0x40cfeeb3 in PresShell::ProcessReflowCommands ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#36 0x40cfeb5f in HandlePLEvent ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libgklayout.so
#37 0x400cdad0 in PL_HandleEvent ()
   from /home/spheara/stevek/src/mozilla/dist/bin/libxpcom.so
#38 0x400cd9c9 in PL_ProcessPendingEvents ()
   from /home/spheara/stevek/src/mozilla/dist/bin/libxpcom.so
#39 0x400ce990 in nsEventQueueImpl::ProcessPendingEvents ()
   from /home/spheara/stevek/src/mozilla/dist/bin/libxpcom.so
#40 0x404d6d00 in event_processor_callback ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libwidget_gtk.so
#41 0x404d6a5b in our_gdk_io_invoke ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libwidget_gtk.so
#42 0x40672afa in g_io_unix_dispatch (source_data=0x82c7cb8,
    current_time=0xbffff394, user_data=0x82c7c90) at giounix.c:135
#43 0x406741b6 in g_main_dispatch (dispatch_time=0xbffff394) at gmain.c:656
#44 0x40674781 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#45 0x40674921 in g_main_run (loop=0x82c7d00) at gmain.c:935
#46 0x4059c8e9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#47 0x404d72b9 in nsAppShell::Run ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libwidget_gtk.so
#48 0x4044da9b in nsAppShellService::Run ()
   from /home/spheara/stevek/src/mozilla/dist/bin/components/libnsappshell.so
#49 0x804e6b7 in main1 ()
#50 0x804ed9c in main ()
#51 0x4023d9cb in __libc_start_main (main=0x804ec3c <main>, argc=1,
    argv=0xbffff644, init=0x804b030 <_init>, fini=0x8055318 <_fini>,
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff63c)
    at ../sysdeps/generic/libc-start.c:92
----- SNIP -----



Steve K: this is getting confusing.  I hope you're not Steve Katz, who has also
commented on this bug.  If you *are* the same Steve Katz, will you please
identify yourself in the future as that same Steve Katz, or login as Steve Katz
@ Sun?

Anyway, for this message, I'll assume you're your own person, and not Steve Katz
@ Sun.  :-)

Recently, Mozilla changed in a way that breaks any released version of Java
Plug-In for the Unix platforms.  The Java Software folks are literally minutes
away from giving new Linux bits to Netscape for testing.  The new bits
accommodate the recent Mozilla change, which had to do with the way a parent X
window was given to a Plugin instance.  It sounds as if this is what you're
running into: your version of Linux Java Plug-In is crashing because it's trying
to de-reference a structure that no longer is a structure.

Steve Katz's message of 10/18/2000 15:08 sort of put this bug on a different
track, talking about whether it's necessary to call XSync() before getting the
window id.  That's a slightly different issue.  The main issue has been
addressed by the Java Plug-In group, and the new Linux Java Plug-In will be
delivered to Netscape soon.

Reviews?  Anyone?

There are definitly two steveks here.  I know this because I am one of them and
I did not write the comments that appear under the the user name Steve K
(stevek@stevek.com). 


*** Bug 56530 has been marked as a duplicate of this bug. ***
Sounds reasonable; how should a prospective reviewer test this without having
the Sun Java bits that actually work?  Incidentally, I don't see a crash using
the 10/23 branch build and the java bits that come with it (but I don't see the
applet either, just the plugin dialog).

How often is GetNativeData called?
For NS_NATIVE_PLUGIN_PORT?  Not very often.

Apparently there's no way for those of us outside of Sun to test this *with*
Java (what's the ETA on getting those revised Java bits?  And what's the bug
number tracking that issue?  Can someone please update us?) but the code looks
fine and doesn't seem to hurt anything running without Java.  It's called three
times on loading a page with one applet when I don't have the Java plugin; on
pages with no applets, it's not called at all.  So this shouldn't hurt
performance on Java pages, and won't affect performance at all on non-Java pages.

r=akkana
akkana: Granrose put the latest bits on the shelf.
bug 57004 is the one following this up. FYI: However, I cannot get java to work 
using complete/custom installation on today's linux branch.
For an Xsync call after a new-X-window protocol operation that has to cohere
with other connections?  a=brendan@mozilla.org

/be
Whiteboard: [rtm need info] → [rtm+]
I cannot visit this page w/o crashing now, linux, branch.
I install the java 2.0 plugin, and then ? VM fails to
initialize at startup, and I crash when visiting this page.
I am also having trouble on Win2000, but that might be
another problem.
Pav, we'd like to have your input on this one.  Is there any potential 
performance degradation for someone downstream?
Whiteboard: [rtm+] → [rtm need info]
here's my console output from my above comment.
This is an installed, netscape branch build from today.
I installed the java 2.0 plugin, restarted, and went
to http://java.sun.com.

There was an error trying to initialize the HPI library.
Please check your installation, HotSpot does not work correctly
when installed in the JDK 1.2 Linux Production Release, or
with any JDK 1.1.x release.
Could not startup JVM properly!
java_vm process: could not start Java VM
INTERNAL ERROR on Browser End: Could not read ack from browser
System error?:: Resource temporarily unavailable

**** crash ****
Check on latest comments on 57004, it may help.
marking dependancy on 57007
Depends on: 57004
This fix has been checked into the tip and the Netscape_20000922_BRANCH branch.
 Please test it when your JRE bits are straightened out.
I just installed the commercial installer with BUILDID 2000102321 and the linux
jre that George gave to you.  I visited java.sun.com and both applets
successfully displayed.

Make sure that the libjavaplugin_oji.so is exactly 349608 bytes in size and has
a checksum of 3203097682.  If it doesn't then you don't have the right java
plugin!



Ed, is that available outside the firewall at all?  I'd like to test this so
that I can close it.  If I have to wait for RTM then that's fine, too.
r=pavlov

selmer: there shouldn't be any real performance hit by adding this.
Linux JRE bits handed over to blizzard via secret email handshake ceremony.  :-)
Yep, seems to work well.  Thanks, George!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified on linux 10/28 branch. adding :vtrunk for verification on trunk. For 
verification, do a custom install and install java plugin and just visit this 
page. 'Industry News' applet Applet (top right) should load and page shud not 
crash.
Keywords: vtrunk
unable to verify on the trunk since mozilla builds don't come with java and the
current java available seems to not be working.  Can we get the commercial java
XPI posted publically for mozilla? :)
asa (and others):  I'm not sure how closely blackdown and sun are tracking each
other here, but blackdown's latest JRE pre-release does work correctly with the
latest mozilla builds.   Using it will verify at least that mozilla's OJI is
interoperable with something, although it won't necessarily guarantee any kind
of success with Sun's reference.

HTH.
-SteveK
Okay, I need help: how do we get the JRE XPI bits to Netcenter for staging?
I'll ask Netscape RE about how to push the bits to Netcenter.
Send me the bits George, rebron@netscape.com in a .xpi format, and I'll post
them to home.netscape.com/plugins/jvm.html

-Rafael
Um. I'm still seeing this on the latest CVS builds.
Um. Of course you are.  Unless you're a Sun or Netscape employee, you can't get 
access to the Java plugin in which this is fixed.

Please see http://www.mozilla.org/oji/index.html#LATEST_OJI
Our J2SDK/RE 1.3.0 includes a plug-in that works with the latest CVS
code (and M17/M18).  See http://www.blackdown.org/java-linux/mirrors.html

working fine on trunk build 2000111608. VERIFIED. I did a installation of java
plugin from the netcenter website and applets are loading fine and I see no crash.
Status: RESOLVED → VERIFIED
*** Bug 57400 has been marked as a duplicate of this bug. ***
Keywords: vtrunk
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.