310691 - Java text is apparently not updated in timely fashion

Status: VERIFIED WORKSFORME

(Camino Graveyard :: Plug-ins, defect)

Description

[dave oshel]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050930 Camino/1.0a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050930 Camino/1.0a1+

The upper portion of the java applet from NIST.time.gov does not properly
update, such that the entire text is displayed:

10:51:38
Saturday, October 1, 2005
Accurate within 0.3 seconds

Sometimes nothing, sometimes top line only, sometimes everything if you cover
the window with another window, then click on the WWV behind (force general redraw).

Reproducible: Sometimes

Comment 1

[Samuel Sidler (old account; do not CC)]

WFM using 9/28 branch build.

What exactly are you seeing? Can you please take a screenshot of the "bad"
behavior? Also, what OS are you running?

Comment 2

[dave oshel]

1. No.  It's intermittent.  Maybe a low memory phenom.
2. Macintosh OS X 10.3.9, Camino 20050930

Comment 3

[Samuel Sidler (old account; do not CC)]

Smokey, can you take a look at this on 10.3 and see if it's a 10.3-only problem.
Also, someone with lower memory on 10.4 should give it a try. I definitely can't
reproduce.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It's definitely intermittent.  The first time I loaded the page, only the third
line ("accurate") did not show up.  The next several time, all lines showed up.
 Then I left it in a bg tab, and when I switched back, only the time was
visible.  The next time I switched back to the tab, everything was visible again.

Comment 5

[dave oshel]

Attachment: screen dump showing bug (tiff file)

Comment 6

[dave oshel]

Attachment: screen dump showing missing text

Comment 7

[dave oshel]

This may be related to Apple's recent Java security update?

Comment 8

[Samuel Sidler (old account; do not CC)]

I'm going to guess this is 10.3 only (maybe 10.2 as well) since I can't
reproduce this bug at all. It'd be good if someone tried on 10.2 and also 10.4
to confirm that it works. For the record, I *haven't* installed the latest Java
updates yet.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I'm not able to reproduce this at all ... though not for lack of trying :-)

I tested with the two newest available Camino nightlies (2005-09-30-04-1.0 and
2005-09-30-08-trunk) on OS X 10.3.9, 10.4.2 and 10.2.8.  I played all kinds of
tricks that have in the past caused display problems -- like hiding with
Command-H and then restoring, or opening a new window above the existing
window (with Command-N) and then closing it (with Command-W).  On OS X 10.3.9
I even tried turning off one of my CPUs (I have a dual-1Ghz-cpu PowerPC G4
desktop).  I didn't see the tiniest problem.

It will help if those of you who've been able to reproduce this can give some
clues about which user-interface actions tend to trigger this problem.

I wonder if your connection speed might play a role.  I have a 1.2 megabit
ADSL connection.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

I forgot to mention that I've installed Apple's Java Security Update on OS X
10.3.9 and their Java 1.3.1 and 1.4.2 Release 2 on OS X 10.4.2 -- so that
doesn't seem to be a factor.

I also played around a bit with switching this applet to and away from a
background tab -- I didn't see any problems.

Comment 11

[dave oshel]

Connection speed is vanilla top-end DSL, probably not as fast as yours.  I'm
using an old dual-USB white chiclet iBook with 256 Mb RAM.   The iBook is a
notorious bottleneck for memory-intensive tasks like QuickTime, but Java has
never given me any problems.  I agree, if it weren't for the screen shots... :)

Comment 12

[Torben]

I was able to reproduce this once, OSX 10.2.8, Camino 2005091409 (v1.0a1), iMac
G4 800MHz, 512MB.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Everyone should be testing on Camino nightlies that bundle the latest version
of the Java Embedding Plugin (0.9.4+a) -- those dated 2005-09-28 and later.
Tests on earlier versions aren't particularly meaningful.

I won't be able to do anything about this until I'm able to reproduce it.  So
it's important that someone find a way to reproduce the problem reasonably
consistently (say at least 50% of the time), and let us all know about it.
This means that if you see the problem, you should try to remember what you
did just before it happened, and keep trying those things again until the
problem recurs.  (Here I'm assuming that the problem is triggered by some kind
of UI action.)

If the problem is caused by Java running out of memory, you should see error
messages in the Java Console.  (If you're using the Java Embedding Plugin (as
you should be), the best way to see these messages is to look at the Java
Console.log file in the Library/Logs/ directory under your home directory.
The file only contains messages from the most recent JVM session.)

In fact you should look for error messages (and any clues they may provide) in
both the Java Console and the "system" console (accessible via the Console
utility).

Comment 14

[Torben]

Attachment: Java Console Log

I can reproduce this bug most of the times doing this (Camino 2005093004
(v1.0a1+), system as in comment 12):

1) Load this bug
2) Load the url in a new tab
3) When the applet has finnished loading open a new window
4) Switch back to the applet

If I switch tabs between 2) and 3) the bug does not appear.

The Java Console gives this error (see attachment):
java.lang.IllegalStateException: Timer already cancelled.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I tried your procedure several times each on OS X 10.2.8, 10.3.9 and 10.4.2
... and never saw the problem.

> 4) Switch back to the applet

Please be more precise.  Each time I opened a new window (using the menu or
Command-N), the applet (in the old window) was completely obscured.  So I
needed either to click somewhere on the applet's window (but outside the
applet), or to move the new window aside (or close it or minimize it) and then
click directly on the applet.  Neither action triggered the problem.

> java.lang.IllegalStateException: Timer already cancelled.

I've seen this error occasionally, with different applets.  I've always
assumed it was caused by errors in those applets.  I don't believe I've ever
seen a case where this error coincided with a visible UI problem.

> Tue Oct 04 10:51:35 CEST 2005 JEP creating applet utcnist4 (http://nist.time.gov/)

> Tue Oct 04 08:51:52 GMT 2005 JEP creating applet utcnist4 (http://nist.time.gov/)

> Tue Oct 04 08:52:28 GMT 2005 JEP creating applet utcnist4 (http://nist.time.gov/)

Your log contains several lines like this (these are the first three).  These
are logged by the JEP.  They show that you reloaded the applet several times
during your browser session (i.e. between the time you started Camino and quit
it).

What's odd is that the timezone changed between the first timestamp and the
second one.  That doesn't happen in my tests.  Maybe _this_ is a clue to why
you're seeing the problem, but I'm not.

Do you have any idea why the timezone changed?

(The timestamp is generated in Java code using "System.out.println(new Date()
... )".)

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> Do you have any idea why the timezone changed?

I just tried "Change timezone" in the applet (which seems to reload the applet
using a different URL) -- this didn't cause any change in the timezone of my
timestamps.

>> java.lang.IllegalStateException: Timer already cancelled.
>
>I've seen this error occasionally, with different applets.  I've always
>assumed it was caused by errors in those applets.  I don't believe I've ever
>seen a case where this error coincided with a visible UI problem.

I forgot to mention that I don't see this error at all.

Comment 17

[dave oshel]

>Everyone should be testing on Camino nightlies that bundle the latest version
>of the Java Embedding Plugin (0.9.4+a) -- those dated 2005-09-28 and later.
>Tests on earlier versions aren't particularly meaningful.

The info.plist for

/Applications/Camino.app/Contents/MacOS/plugins/JavaEmbeddingPlugin.bundle

shows:

	<key>CFBundleVersion</key>
	<string>0.9.4+a</string>

Looks jake to me :)

Comment 18

[Torben]

(In reply to comment #15)
> I tried your procedure several times each on OS X 10.2.8, 10.3.9 and 10.4.2
> ... and never saw the problem.
> 
> > 4) Switch back to the applet
> 
> Please be more precise.

I clicked on the application's window's titlebar (but that obviously didn't work
for you)
 
> > java.lang.IllegalStateException: Timer already cancelled.
> 
> I've seen this error occasionally, with different applets.  I've always
> assumed it was caused by errors in those applets.  I don't believe I've ever
> seen a case where this error coincided with a visible UI problem.

Upon further testing, I can get thiserror without any visual disturbution and I
can get visual disturbution without this error :-/

> > Tue Oct 04 10:51:35 CEST 2005 JEP creating applet utcnist4 
> > (http://nist.time.gov/)
> 
> > Tue Oct 04 08:51:52 GMT 2005 JEP creating applet utcnist4 
> > (http://nist.time.gov/)
> 
> > Tue Oct 04 08:52:28 GMT 2005 JEP creating applet utcnist4
> > (http://nist.time.gov/)
> 
> Your log contains several lines like this (these are the first three).  These
> are logged by the JEP.  They show that you reloaded the applet several times
> during your browser session (i.e. between the time you started Camino and 
> quit it).
> 
> What's odd is that the timezone changed between the first timestamp and the
> second one.  That doesn't happen in my tests.  Maybe _this_ is a clue to why
> you're seeing the problem, but I'm not.
> 
> Do you have any idea why the timezone changed?

No idea, but I always get a different timestamp at the first run and the
subsequent runs of the applet.

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Has anyone seen this in a build *after* the 30th?  I haven't been able to
reproduce at all, and before it was at least often enough to confirm the bug.  

I ask because I believe bug 298961 landed on the branch the afternoon of the
30th and it seems vaguely possible that fix could have helped the applet better
know when to refresh (still doesn't explain Steven not seeing it in the 30th's
builds, though, when Torben did).

Comment 20

[Steven Michaud [:smichaud] (Retired)]

I suspect this problem is due to bugs in the applet, and doesn't have a UI
trigger ... but it's really hard to be sure.

Torben, please try to reproduce this problem in Safari, and in Camino without
the JEP (i.e. using Java 1.3.1).

To use recent Camino builds without the JEP, make sure
JavaEmbeddingPlugin.bundle and MRJPlugin.plugin have been removed from both
Camino's Contents/MacOS/plugins directory and your system's /Library/Internet
Plug-Ins directory.

Comment 21

[Torben]

> Torben, please try to reproduce this problem in Safari, and in Camino without
> the JEP (i.e. using Java 1.3.1).
 
Easilly reproducible in Safari (1.0.3 (v85.8.1)): Open this bug, open applet in
new tab, switch between the tabs, reproducible 8 of 10 times.

> Has anyone seen this in a build *after* the 30th?  I haven't been able to
> reproduce at all, and before it was at least often enough to confirm the bug.

Tried with the latest nightly (2005100604 (v1.0a1+)) and so far I haven't seen
this bug, neither with or witout the JEP. If SM want, I can try the older build
without JEP on Monday.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

> If SM want, I can try the older build without JEP on Monday.

Please do.  Thanks in advance!

Comment 23

[Torben]

> try to reproduce this problem [...] in Camino without
> the JEP (i.e. using Java 1.3.1).

Just reproduced with build 2005093004 (v1.0a1+) without JEP.

Comment 24

[Steven Michaud [:smichaud] (Retired)]

So this bug seems to have gotten fixed in recent Camino builds, around the
time the fix for bug 298961 was landed (which seems to have been 2005-10-01
for the branches).  So it appears that Smokey's right.  And the connection of
the bug with tab switching tends to confirm it.

I'm still puzzled why the JEP was effected (even rarely) by bug 298961 -- I've
known about this problem for a long time, and the JEP contains workarounds for
it.

And it's interesting that Torben's old copy of Safari seems to have the same
bug.

But now that the problem's fixed, I'm not much inclined to spend more time on
it :-)

Comment 25

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

And on that note, unless anyone can repro this with a nightly build after the
5th, I'm going to close this as WFM.

Reporter, does a current nightly build work properly for you?

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Oops, should have done this ages ago.