466666 - Problems painting Java applets with too small a viewport and multiple applets in page

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[James Linder]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Build Identifier: Firefox/3.0.4

When an applet's canvas is larger than the viewport on the document containing the applet, repainting of the applet does not always work correctly.  The primary case is:

- when there are multiple applets and the last applet on the page has its 
  bottom cut of and not visible in the viewport on the document, the 
  last applet repaints on moving focus to another application but on FF 
  regaining focus, the applet canvas disappears 

There are other cases in which this occurs, such as:

- when there is a single, large applet, resizing the window causes the 
  applet to not paint itself (more difficult to reproduce, happens more 
  reliably when using java 1.5 vs. java 1.4)
- when the document is opened in a window with a viewport too small
  to display all the applets, some of the applets don't render correctly/fully




Reproducible: Sometimes

Steps to Reproduce:
Note:  A zip file attachment will be added to this bug.  These steps for reproduction reference files in the attachment.

For the primary case in the details:

a) Open the file multiple_applets.html in FF3 on OS X
b) Be sure the window is scrolled to the top of the document
c) Resize the window so only part of the bottom applet is visible in the viewport
d) Observe the applets; they may or may not all be displayed
e) cmd-tab to another application 
f) Observe that the applets are all displayed in the viewport
g) cmd-tab to FF3
h) Observe that the bottom applet is not redrawn/displayed


For the single large applet case in the details:

a) Open the file single_applet.html in FF3 on OS X
b) Resize the window so the entire applet is displayed (600x600 px)
c) Observe that the applet should be painted correctly (10 icons on the left, a paint counter on the right)
d) Resize the window so only a small portion of the applet is displayed in the viewport (about 200x200 or fewer pixels)
e) Observe that the applet did not get redrawn/displayed
f) If the applet is displayed, resize to make the viewport smaller and re-observe the results
g) If the applet is still displayed correctly, resize the window and then while the applet is rendering, resize the window again; re-observe the results

For opening the document in too small a viewport case in the details:

a) Open FF3
b) Resize the window so its viewport height is < 600 px tall
c) Open the file multiple_applets.html in
d) Observe that one or more of the applets (usually the top applet) is not entirely/correctly rendered



Actual Results:  
In one or more of the above states, the applets are not redrawn/displayed correctly.  Part or all of the applet disappears or is not drawn.

Expected Results:  
The applets should be redrawn and visible on alt-tabbing back into FF3 (the primary case), when the viewport is very small (secondary case 1) and when opening a document containing applets in a window that doesn't fit all the applets (secondary case 2).

I have tested the JEP plugins back to 0.9.6 and this problem occurs in all versions.  It is a little more difficult to reproduce the problem in 0.9.6 and 0.9.6.1 than in 0.9.6.5.  Also, I have pinpointed the problem to being in the first FF3 nightly that actually loaded the applet: 2007.04.05.  It is also the first nightly that contained JEP 0.9.6.1.

It seems that this is a redrawing problem.  In the multiple applets version, Safari (version 3.1.2 (5525.20.1)) consistently sends redraw commands to all the applets on alt-tab away and alt-tab back to Safari.  However, in FF3, the redraw commands get sent to the applets inconsistently.

When running the examples in FF2, the applets work as expected.

I have run tests using Java 5 and Java 1.4 on OS X 10.5.5 and on OS X 10.5.3.  The primary problem and the secondary problem 2 happen with FF3 on all four combinations.  The secondary problem 1 is more difficult to reproduce using Java 1.4 but still happens sometimes.

Comment 1

[James Linder]

CCing Steven Michaud

Comment 2

[James Linder]

Attachment: Example applet that causes the issue

This attachment contains a sample applet that causes the issue.  Setting up the applet for testing can be done with the following commands:

  cd <your download directory>
  tar -zxvf example.tar.gz
  cd example/src
  javac -target 1.4 -source 1.4 *.java

Then open the following .html files in FF3 as the reproduction steps explain:

  example/src/single_applet.html
  example/src/multiple_applets.html

Comment 3

[Steve K]

This is actually reproduced on intel; not PPC (although probably not architecture-dependent).

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I can reproduce most of what you report ... though only with multiple
applets on a page (your multiple_applets.html example).

The problems are easier to reproduce on an old PPC G4 running OS X
10.4.11 than on a fast Intel MacPro running OS X 10.5.6 -- which
probably just means the problems are worse on slower machines.

Some of the problems might be a little harder to reproduce in recent
Minefield nightlies than they are in Firefox 3.0.5 ... but this is
subtle, and I'm not sure I'm right about it.

Only one of the problems can be reproduced on Firefox 2.0.0.20, even
on my old, slow G4.

As you've noticed (elsewhere), the code that decides which updates to
pass to Java from the browser is very complex.  So much so that it
quite likely contains some bugs.  But Firefox has always been grossly
excessive in the number of updates that it passes to the Java plugin.
And the NPAPI plugin interface has the design flaw that it can't pass
partial updates -- only ones that update the entire plugin.  So
without this complexity, the situation would be far worse.

Now that I'm working full time on Mac Firefox (Cocoa widgets and the
plugin interface) for Mozilla Corp, I don't have as much time as I
once did to devote to the JavaEmbeddingPlugin.  But in this case, I'd
hesitate to do anything even if I was still working full time on the
JEP.  Because of the update-filtering code's complexity (and the
complexity of the problems that it remedies), it's difficult to change
one piece of it without making other problems worse.

Moreover, in my tests only pages with multiple applets are effected --
which means that most users of Java applets don't see these problems.

Finally, the fact that the problems are worse in Firefox 3.X than they
are in Firefox 2.X (with the same version of the JEP) shows that the
burdens the update-filtering code has to bear have only grown heavier
in Firefox 3.X.

For these reasons, I'm not going to be able to address these problems
anytime soon ... at least in the JEP.

For some time I've been looking for ways to alleviate this problem (of
excess updates) from the browser side.  But (for whatever reason)
other plugins don't seem to be as badly effected by the excess updates
as the JEP.  And so (naturally), on the Firefox side this problem
doesn't have the urgency that it does from the JEP's point of view.

Nonetheless, two patches have been landed recently that may start to
make a difference -- for bug 465732 and bug 459319.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

In FF 3.X I can reproduce the first and third sets of steps-to-reproduce from comment #0, but not the second.

In FF 2.X I can only reproduce the third set.

Comment 6

[Steve K]

Thanks for the updates, Stephen.

Although in the examples given, these problems are only (currently) reproducible in the multiple-applet case, we are seeing them in single-applet cases as well.  However, in these cases, frames are involved, and there _are_ applets in multiple frames.

Given the complexity of digging into the JEP, and your availability, we've been looking at some workarounds in the java code itself.  Currently, doing something as simple as this is working as expected (refreshes display within 3 sec):

<snip>
if(true) // TODO: do this only on mac/firefox
{ 
        System.err.println("start(): initiating repainting timer for
Mac/Firefox");
        ActionListener repaintAction = new ActionListener() { 
                public void actionPerformed(ActionEvent e) { 
                    // System.err.println("Repainter: painting..");
                    // When the problem we're trying to happen occurs, calling
repaint doesn't have any affect.
                    //repaint();
                    paint(getGraphics());
                } 
        };
        new javax.swing.Timer(3000, repaintAction).start();
} 
</snip>

I'm not quite up to speed on current Java drawing semantics, so I'm not sure if the fact that repaint() doesn't seem to work is expected, or a useful piece of information.  Because it has no effect (instrumenting paint() and update() methods in the JApplet shows that when the problem is occurring, paint() or update() are not called), it almost seems as if there's some kind of cliprect optimization going on somewhere, that gratuitously calling paint() avoids.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I've released a new version of the Java Embedding Plugin (0.9.7) that
may help alleviate the symptoms of this bug -- particularly what
happens when you switch to or from a window containing Java applets.

See bug 488746.

Comment 8

[Benjamin Smedberg]

Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.