313617 - Some java applets won't start (beginning 26 Sep 2005)

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[walter sheets]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1

Beginning with Boris's check-in of 2005-09-25 (18:27) (See bug 309986) some java
applets fail to initialize and run.  (This affects both firefox-trunk and seamonkey-trunk.)

The status bar says 'applet loading' then 'applet started' but nothing actually
happens.  Most applets seem to work, but a few don't, and the URL above seems to
show this problem most consistently.  I even saw this problem once when running
the wire-frame demo applet from the sun jdk14, but clicking on 'reload current
page' got the applet running okay.

Reproducible: Sometimes

Steps to Reproduce:
1.Use any firefox-trunk or seamonkey-trunk from after 2005-09-25
2.Load the URL listed above, and watch the status bar.
3.

Actual Results:  
The java applet gets 'loaded' and 'started' but does nothing.

Expected Results:  
The applet should display barcharts of four different foreign currencies in real
time.

See my comments to bug 309986 for another URL to try -- that java applet will
sometimes work and sometimes not, but it does demonstrate the problem if you keep
trying.

I suspect that Boris's check-in merely unmasks a bug rather than causing one.
Originally, this applet problem was also causing crashes in addition to the
problem I describe here, but the crashes have been fixed already (bug 312055).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem in builds in which bug 313440 is fixed?

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1 ID:2005102313

This one WFM.

Comment 3

[walter sheets]

(In reply to comment #1)
> Is this a problem in builds in which bug 313440 is fixed?

Still a problem in the most recent daily build (2005-10-24)
and in my own CVS build of a few hours ago.

Comment 4

[walter sheets]

(In reply to comment #2)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051023
> Firefox/1.6a1 ID:2005102313
> 
> This one WFM.

Hmm.  I just filed a talkback report on the daily build from today, because
it crashed when I tried to load the URL I specified.  The firefox release
1.0.7 for Windows works as expected.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm...  The page in the URL field worskforme as far as I can tell....

Comment 6

[Ria Klaassen (not reading all bugmail)]

It crashes terribly with Adblock installed: TB11062987E TB11062974Y 

Comment 7

[Ria Klaassen (not reading all bugmail)]

Regression range: 1.9a1_2005092110 - 1.9a1_2005092123, if this is of any help.

Comment 8

[Ria Klaassen (not reading all bugmail)]

Adblock Plus 0.5.9.

Comment 9

[Ria Klaassen (not reading all bugmail)]

This talkback is from the latest nightly: TB11066796G
The other two were from the latest hourly.

Comment 10

[Boris Zbarsky [:bzbarsky]]

The adblock issue is known, and covered by a different bug.

Comment 11

[walter sheets]

(In reply to comment #5)
> The page in the URL field worskforme as far as I can tell....

On linux, Windows, or both?  Firefox-trunk, or seamonkey-trunk?
I just tried both firefox and seamonkey on Windows and both crash
when loading the URL.  You don't see this?  (I'm not using adblocker.)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Firefox and seamonkey trunk, both on Linux.

Comment 13

[Andrew Schultz]

worksforme with linux seamonkey trunk 2005102605 and Sun Java 1.5.0_05.
What JRE do you have?

Comment 14

[Andrew Schultz]

and do you see any errors in the java console?

Comment 15

[walter sheets]

(In reply to comment #13)
> worksforme with linux seamonkey trunk 2005102605 and Sun Java 1.5.0_05.
> What JRE do you have?

Java(TM) Plug-in: Version 1.4.2_09

Aha -- Java 1.5.0_05 worksformetoo!  Strange that 1.4.2 stopped working
correctly after 2005-09-25.

Comment 16

[Tomi Leppikangas]

I think that same bug affects other plugins too. Mozplugger doesn't allways
show embedded videos on slow servers/pages.

Example url http://www.big-boys.com/articles/48in.html
doesn't show at first load, buf it you load other page and go back, then
video shows ok.

Problem exists in todays nightly build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051027 Firefox/1.6a1).

Comment 17

[Tomi Leppikangas]

Attachment: short testcase for <embed> plugin not working

Here is short testcase showing problem with mozplugger. It doesn't work with new nigtlys, but older it works. I tryed to make same thing with javaplugin, but i didn't get it to fail.

One thing that i notised when i turn mozplugger debug on, was that NPP_NewStream() gets called before NPP_SetWindow() in new nightly, but in older build it is NPP_SetWindow() first and then NPP_NewStream(). So there is data coming from stream but nowhere to display it.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

oh... that wasn't so much intentional... although I'm not sure that a plugin has to care (it can just build up its internal datastructures or whatever anyway, and just render the stuff once SetWindow does get called)

but I should probably find a way to restore previous behaviour...

Comment 19

[Boris Zbarsky [:bzbarsky]]

Can we really guarantee calling SetWindow before NewStream if we move plugin loading to content?  Or should that ordering be something we work hard to preserve even as said move happens?

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

mm... we ought to be able to call SetWindow(NULL) at least

Comment 21

[Tomi Leppikangas]

Attachment: NSPR log when loading avi (works ok with mplayerplug-in)

This is nspr log with: NSPR_LOG_MODULES=objlc:9,PluginNPN:9,PluginNPP:9,Plugin:9
With mplayerplug-in v3.15 loading url http://www.student.oulu.fi/~tomilepp/pics/vasara.avi

This loads ok, no errors.

Comment 22

[Tomi Leppikangas]

Attachment: NSPR log when loading testcase (firefox hangs with mplayerplug-in)

This is NSPR log when loading testcase.
firefox hans or crashes.

I think mplayerplug-in should handle case where NewStream is called before SetWindow. There seems to be something else going on.
There seems to be 2 NewStream calls, where there is only one when all works.

Comment 23

[Kurt Weinschenker]

Attachment: Mac OS X crashlog from above URL

Above URL crashed Camino trunk nightly build just as Java applet was starting.  Camino trunk build 2006101622 (v1.2+) was running under Mac OS X 10.3.9.

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Biesi: let me know if you think this isn't critical enough to block.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 381512 should help here (can't test mplayer right now)

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

Hmm, I can't reproduce the mplayer issue on current trunk (without that patch).

What mplayerplugin version are you guys using? I have version 3.31.

Comment 27

[Tomi Leppikangas]

I tested todays nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007080304 Minefield/3.0a7pre) and crash with mplayer seems to be fixed.
My mplayerplug-in is version 3.40.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

worksforme, then.