Closed Bug 311843 Opened 19 years ago Closed 7 years ago

browser freezes when java applet calls showDocument()

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bassclar, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

This is a regression. It works fine in Firefox 1.0.4. (I have not tried the
first beta of 1.5/1.8.)

See "steps to reproduce" below for details. I don't have time right now to
explore this further, but I'm reporting it anyway to give the developers a
heads-up on a crashing bug.

After a period of busy days ends, I'll do some testing on other platforms and
report my findings. I'll also write my own applet with ShowDocument() calls, try
it out, and report how it does.


Reproducible: Didn't try

Steps to Reproduce:
1. sign in to your account at hollywoodpoker.com and play a hand in their java
applet
2. click on the "prev hand" button to have the applet call showDocument() to
present a hand summary in a new (non-java) browser window
3. 

Actual Results:  
freeze of all browser windows (The new browser window does not show.)

Expected Results:  
New browser window with hand history should appear. Other windows (both java and
non-java) should not be frozen.

My appologies if "OS integration" is not the correct Component for this bug. I
find it hard to choose. Java isn't really an OS, but it's not part of mozilla,
so maybe it's close enough.
Please try to find a page on hollywoodpoker.com that doesn't require you to
create an account (and presumably to pay lots of money).

Or I'll just wait for your applet.

But, in my experience, AppletContext.showDocument() works just fine.  Here are
two applets that use it.  In the first of them, when you click on the
programmer's face (!), a call to showDocument() takes you to Sun's main Java
page.  In the second, after your speed test is finished a call to
showDocument() takes you to a page showing the results of your test.

http://java.sun.com/applets/jdk/1.4/demo/applets/ImageMap/example1.html
http://speed.try.wideopenwest.com/


Well one can create a play-money account on hollywoodpoker.com. When I did I
didn't even have to give any identifying info other than a valid email address.
But I'm not suggesting you (or anyone else) do that.

I'm not sure what the the poker applet is passing as the second argument to
showDocument(). It's behaving as if it were "_blank", but perhaps it's a
different unique string each time or something. I'll look into it, but might not
have time for a week or so.

If I'm the only one this is happening to, then great. I thought I should report
the bug, though, just in case.
Version: unspecified → 1.5 Branch
I was thinking that perhaps this bug was specific to MacOSX, which
could explain why you might not have trouble while I do. Preliminary
testing doesn't support this, though.

Here's a URL one can use to test showDocument() in java applets:
    http://spot.infosyslabs.com/~bcole/ShowDocument.html

Alas, it seems to work fine with beta2 of 1.5/1.8. I'll try to
perform other reproducibility tests before too long.

Sometime in the next few weeks I'll try writing my own applet, too.

In the meantime, thanks for your demo URL
(http://spot.infosyslabs.com/~bcole/ShowDocument.html) -- I've seen several
examples of applets that use showDocument() with the second parameter "_blank"
or a null, but I wasn't aware of any I could use to test other parameters.

While playing with it, I myself found a problem -- a very obscure one, which
may or may not be related to the one you report:

Visit your URL and (in the second box) choose "type in your own".  Leave that
text the same (even though it's not a valid URL), and click on "OK".  The URL
from the first box will open in another window.  If you're doing this for the
first time, the second window will be opened and become key (it will be on
top).  Otherwise the first box's URL will still be opened in that second
window, but the window will stay behind.

If the second window (the one that showDocument() opened a URL in) is on top,
click anywhere on the first window (the one containing the applet) to put that
back on top.  Then click anywhere in the second window _except_ the title bar
-- the second window won't be made key (it won't be put above the first
window)!  If you click the second window on the title bar, the problem goes
away.  But it happens again if you repeat my procedure.

I assume this is some kind of bug in the Java Embedding Plugin.  If it is, I
hope to fix it in the next version of the JEP.


(Oops, I dropped the first part of my comment.)

I'm working with a Mac, too.  I'm the author of the Java Embedding Plugin,
which is bundled with recent versions of Mozilla.org browsers for the Mac --
including Firefox 1.5 Beta 2 (what you're using).

http://javaplugin.sourceforge.net/
http://www.mozillazine.org/talkback.html?article=7230


I'm glad you like my applet.

I am able to reproduce the bug on hollywoodpoker.com, but
not with the applet. I tried to be more careful this time
in examining the symptoms.

This time the applet froze (both windows it had open) but
other browser windows were ok. I could even launch another
applet from one of the other windows. Things were sluggish,
though, as if something was chewing cycles. There is a
chance this is also how it was last time.

Also, this time, I was able to close the applet window (the
original of the two showing) with the red close button. I'm
pretty sure I was _not_ able to do that last time, though
perhaps I was trying to close the second window.
I can't do anything (about your problem, at least) until I'm able to reproduce
it.  I'm not going to try hollywoodpoker.com until you tell me how to get a
"play money account", and _precisely_ (step-by-step) how to use it to recreate
the problem you've been having.

Otherwise, I'll wait for you to write an applet (another one) that
demonstrates your problem.


When going to hollywoodpoker.com's java applet, the
first window is the "lobby" window, which resides in a
browser frame. From there one pops up "table" windows,
which are presumably JFrames or something.

I installed Firefox 1.5beta2 on a turion machine running
XPproSP2 to try to exercise this bug. ShowDocument worked
from the lobby window, but failed from table windows. It's
a different kind of failure, though. It doesn't freeze or anything,
but nothing happens. The button displays it's visual feedback
on the press, but it behaves as if it hadn't been pressed.

Actually, that's not quite true. The pop-up blocker did realize
that I had pressed the button, and showed me a list of URLs
that I had tried to go to via showDocument from the table
window. After seting the pop-up blocker to allow all popups
form hollywoodpoker, it still did nothing from the table windows.
Crazy eh?

When I tried my ShowDocument applet from this XP box,
it did nothing with "_blank" target, but worked fine with
"_self" target. (Perhaps I should modify the applet to pop
up a JFrame from which showDocument() can be called.)

Next up, testing on a blue&white G3 running osX 10.3.9.
Invoking showDocument() from the lobby window was fine.
Invoking showDocument() from the table window froze both
the lobby and table applet windows, but not other firefox
windows.

Finally, testing a G4 iBook running osX 10.4.2 behaved
exactly like the blue&white G3.

I'm now convinced that this bug is not specific to me or
my machine, but is reproducible by the public at large.
I guess now I'll work on step-by-step details as per
comment #7.
bwt, I noticed a different applet-related bug. If I have the lobby window
open, a table window open, and some non-poker related browser window
open, only the lobby window and the non-poker windows will be listed in
the "Window" menu. This is probably not a bug.

But when the table window is active (topmost), then selecting the non-poker
window's menu item from the Window menu doesn't work. I would call that
a bug. (It works fine if the lobby window is the active (topmost) window.)

Should I file this as a separate bug?

I should have mentioned that the behavior of
commet #9 is not specific to Firefox 1.5. The
same thing happens in Firefox 1.0.x.

The showDocument() problems didn't happen
in Firefox 1.0.x.

a partial mea culpa on comment #8:

There is no difference in behaviour between a showDocument()
from the lobby window and a showDocument() from a table window.

I was confused because there are some buttons on the lobby window
that are not part of the java applet. They, of course, work fine.
In my confusion I thought they were part of the applet.

But it is possible to navigate to a place on the lobby window
which invokes showDocument() and it behaves the same as with
the table applet. That is, it crashes on the three osX machines
which I've tried, and does nothing on the two windows machines
I've tried.
This is all pretty academic (to me at least) until you either enhance your
applet to reproduce one or more of these problems (which is what I'd prefer),
or you provide step-by-step instructions to reproduce them at the
hollywoodpoker.com site, using free registration and no actual money (which is
second-best, but is better than nothing).


I have also encountered this problem using Firefox 1.5 on Mac OS 10.3.9.  The problem appears to be specific to applets that open a new window.  Here is a simplified applet that demonstrates the problem:

  import java.applet.AppletContext;
  import java.awt.BorderLayout;
  import java.awt.event.ActionEvent;
  import java.awt.event.ActionListener;
  import java.net.URL;

  import javax.swing.JApplet;
  import javax.swing.JButton;
  import javax.swing.JFrame;

  public class TestApplet extends JApplet implements ActionListener {
      public void init() {
          JButton b = new JButton("works");
          b.addActionListener(this);
          this.getContentPane().add(b, BorderLayout.CENTER);
        
          JButton b1 = new JButton("broken");
          b1.addActionListener(this);
          JFrame f = new JFrame();
          f.getContentPane().add(b1, BorderLayout.CENTER);
          f.pack();
          f.setVisible(true);
      }
    
      public void actionPerformed(ActionEvent ae) {
          try {
              AppletContext ac = getAppletContext();
              System.out.println("Before showDocument: " + ac.toString());
              ac.showDocument(new URL("http://www.varju.ca/test/jep/success.html"), "_blank");
              System.out.println("After showDocument");
          } catch (Exception e) {
              e.printStackTrace();
          }
      }
  }

This can be seen in action here:

  http://www.varju.ca/test/jep/
Excellent work, Alex. I've been busy
lately and haven't been able to work
on this, but I don't think I would
have been able to discover what you
managed to find anyway.

Who knew that it mattered whether the
_button_ was on the main applet page
on on a popped-up frame? It kind of
seems crazy, even, since it's the exact
same event handler in either case.

But I can confirm that running the applet
at http://www.varju.ca/test/jep/  and
pressing the button labeled "broken" does
indeed freeze all java--not only the applet
with the works/broken buttons, but also any
other applet that was running and any future
applet the user might try to run.
Well perhaps I overspoke. It seems that
it doesn't always freeze "any other applet
that was running and any future applet the
user might try to run," though it would do
this sometimes.

The applet with the works/broken buttons
always freezes, though.

Thanks, Alex, for your test case!

I've used it to reproduce the problem, and now I understand how to fix it.

The problem occurs when showDocument is called from a Java window (such as
your test case's JFrame object) that was popped up by a Java applet.  When
this happens, the freeze doesn't happen right away -- you can avoid it if the
very next thing you do is quit Firefox.  But if you do almost anything else in
Firefox's UI, you'll get a freeze.

This is indeed a bug in the JEP.  But it's actually caused by a flaw in the
JEP's fix for a Firefox bug -- if you call showDocument several times in a row
on a URL that displays a JavaScript alert box
(e.g. "javascript:doAlert('blah')"), Firefox won't pause between the various
alert boxes, which will lead to a crash.  The bug is that the JEP thinks your
applet's JFrame window is an alert box.  But I've now figured out how to make
the JEP distinguish between an alert box (or something popped up by the
browser) and something popped up by the JVM ... which clears up the problem.

I'll include this fix in my next JEP "nightly", which I'll probably release in
the next few weeks.  It will probably take quite a bit longer for this version
to be bundled in a Firefox release, but when the new JEP version comes out
you'll be able to install it manually (more about that when the time comes).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → smichaud
I've just released a new version (0.9.5+d) of the Java Embedding Plugin that
contains the fix I mentioned in comment #16.

http://javaplugin.sourceforge.net/

Please try it out.

To use the new JEP version, you will need to:

1) Install it in /Library/Internet Plug-Ins/ (according to the instructions in
   the JEP Readme).
2) Remove the old JEP files (JavaEmbeddingPlugin.bundle and MRJPlugin.plugin)
   from the Contents/MacOS/plugins/ directory of your Mozilla.org browser(s).


I have tried the new JEP and it no longer crashes
on showDocument(). Thanks for your effors on this.

I have experienced a couple of oddities, though:
1) Pressing the button on the external frame of
   the applet at http://www.varju.ca/test/jep/
   shows the popup-blocker on the main frame,
   which is great. But I tried another site and
   it didn't show the popup blocker anywhere, so
   nothing would happen when invoking showDocument(),
   which is still much better than a crash. It
   did work ok after I manually added the site
   to the popup allow list.
2) Sometimes when a java external frame is in
   front and I click in a regular browser window
   to bring it to the front, it flashes to the
   front for a fraction of the second but then
   pops behind the java frame. Clickin on the
   title bar of the regular browser window usually
   works fine. This is an intermittent problem.
Whoah. Let me clarify oddity #1.

I was wrong that the popup-blocker didn't show
anywhere. In fact, it tried to show on the window
displaying the applet, but for some reason the
only thing that shows up is the aqua-styled
"Preferences" button. The HTML content surrounding
the applet was redrawn (not quite neatly) on top
of the rest of the content of the popup-blocker.

And if the java external frame is in front and
I click inside a text input box (including this
one labelled "addition comments" in bugzilla,
and also the URL entry box at the top of the
window) on a regular browser window, the browser
window _does_ come to the front, but the focus
remains on the java frame.
So the title bar of the regular browser window
remains greyed out and any keystrokes don't appear
in the text input box but get handled by the applet.

Bassclar, I'm not able to reproduce any of the problems you describe. 

You will need to be _much_ more precise in your descriptions.

I can't do anything about a problem until I'm able to reproduce it.
But (as the history of this bug shows) once I do have enough
information to reproduce a bug, I'm often able to fix it.
Blocks: 353557
fyi, i just opened bug 356866, which also outlines a problem with showDocument() calls in firefox v1.5.0.x and macos 10.4.
No longer blocks: 353557
(In reply to comment #1)
> Please try to find a page on hollywoodpoker.com that doesn't require you to
> create an account (and presumably to pay lots of money).
> 
> Or I'll just wait for your applet.
> 
> But, in my experience, AppletContext.showDocument() works just fine.  Here are
> two applets that use it.  In the first of them, when you click on the
> programmer's face (!), a call to showDocument() takes you to Sun's main Java
> page.
 (snip)
> http://java.sun.com/applets/jdk/1.4/demo/applets/ImageMap/example1.html
> http://speed.try.wideopenwest.com/

I just tried the first page in FF3.01, and had no trouble getting it to hang, but I don't know if it's related to showDocument().  The first time I tried clicking on the face, I went right to Sun's Java page as described.  After that, I went back and tried to find some of the other image map areas by moving my mouse around and watching the borders.  I heard a "chirp" sound when my mouse went over one of the lights to the right of the guy's head, then FF hung a second or two later when my mouse was somewhere to the right of his face as I moved the cursor around more.  I may have clicked somewhere on the map, but I don't remember.  Anyway, my CPU usage went up to 100% for a while, and all windows were affected as described.
Assignee: smichaud → nobody
Component: Shell Integration → Plug-ins
Product: Firefox → Core
QA Contact: shell.integration → plugins
Version: 1.5.0.x Branch → 1.8 Branch
Is this still a problem with recent builds ?
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.