Closed Bug 217715 Opened 17 years ago Closed 17 years ago

Java applet fails to get some of its parameters -- getParameter() returns null


(Core :: Layout, defect)

Not set





(Reporter: pkrasimirov, Assigned: roc)


(Depends on 1 open bug, )


(Keywords: fixed1.7, helpwanted, Whiteboard: fixed-aviary1.0)


(5 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

I use latest java from Sun - 1.4.2. I have tried with Java 1.4.1, 1.3.1, 1.3.2 - same results. 
I open a web-page with java applet in it. The HTML contains APPLET tag with about 900 
PARAM attributes. Some of them are long strings - about 1k or 2k text (no fancy symbols, 
just ascii). 
In the init() of my applet (extends JApplet) I try to read them one after another via the 
getParameter(String) method. Sometimes I recieve (incorrect) null result and I can clearly 
see the correct PARAM code in HTML page. When I recieve the first incorrect null, all other 
getParameter() requests return null, except for the already-recieved parameters (I suppose 
they are cached). 
On a page reload from the server, the applet fails to get the same or different parameter. It 
looks very much to me as a threads race. If I save the HTML page on my disk and I open it 
from there (applet still loads from server) - no getParameter() ever fails. 
I tried to find out on which PARAM number applet fails -- it differs every time. Sometimes on 
the 512-th PARAM, sometimes on 318-th, sometimes it doesn't fail (get them all). 
I tried to start a separate java thread in the beginning of init() and the parent thread goes 
out of init() (returns). The child-thread was responsible to get the applet parameters. It 
resulted no change in behaviour -- same as with no forking. 
The applet always loads correct with MSIE 5.5, 6.0 on Windows 2k/XP with Sun java 1.3.x and 
The applet always loads correct with Konqueror 3.0.5 from RedHat 8 with Sun java 1.3.1 and 
1.3.2. The Konqueror browser crushes when few pages with the applet (with different applet 
parameters) are opened at the same time. The applet was "extends Applet", not "extends 
JApplet" at this time. I don't know if it does matter... 
The applet fails (getParam() returns null) with Mozilla 1.3 and 1.4 on RedHat 8 with java 1.4.2 
plugin ns610 and on RedHat 9 with java 1.4.2 plugin ns610_gcc3.2. 
The applet fails (getParam() returns null) with Mozilla 1.3 and 1.4  on Windows 2k/XP with 
Sun java 1.3.x and 1.4.0. 
The applet fails (getParam() returns null) with Mozilla 1.3 and 1.4 on Debian unstable (nightly 
updated) with java 1.4.2 plugin ns610_gcc3.2. 
The applet fails (getParam() returns null) with Konqueror 3.1, 3.1.1, 3.1.2, 3.1.3 on Debian 
unstable (nightly updated). 

Reproducible: Always

Steps to Reproduce:
1. Create a web-page with APPLET and 900 PARAM attributes. I doubt the lenght of PARAM's 
values does matter. Some of mine are empty (""), some are 2k ascii-text long. 
2. Make the web-page available via a server. I serve it with tomcat and it is generated 
on-the-fly, so there is delay (downloads slow). 
3. Write applet that tells'ya on which PARAM it recieves null. 
4. Open the page with Mozilla. 
Actual Results:  
getParameter(String) returns null and I clearly see the PARAM attribute - it is not null. 

Expected Results:  
Mozilla should give to my applet the requested parameter's value.
Assignee: idk → joshua.xia
Component: Java-Implemented Plugins → OJI
You can see example of this bug at - use guest/novuser to login, 
then click "reports" on the left and then click the left eye-view icon to open the report with 
applets. If some parameters are not found the curve won't be displayed. So if you see curves 
1/4, 2/4, 3/4 and no 4/4 curve, this means that some applet parameters are missing. 
Assignee: joshua.xia → kyle.yuan
Ever confirmed: true
When clicked the "reports" link, I only saw the "Loading. Please wait..." in the
main screen, there is no applet. Reporter, did the test site change?
We upgraded our server and it is now able to generate web-pages more quickly. This reduced 
the occurrence of the bug on all client machines. 
The bug is more often seen on slow mashines running Mozilla. On Pentium4 at 2.4 GHz the 
bug almost never appears. On Pentium3 at 600 MHz the bug can be seen very often. 
The test site does not work anymore. The applet was rewritten to avoid the bug. Instead of 
getting all of its data from the PARAMs in the web-page, the applet now fetch data via 
another TCP connection back from server. 
The bug in Mozilla remains. The bug is also found in the Phoenix/Firebird/Firefox browser. 
The bug can be reproduced with high probability when a HTML page is slowly passed to 
Mozilla and Mozilla is running on slow machine. 
In the testcase I just attached, I created a simple applet with ~10000
parameters. In applet's init() method, I try to get all of them. Save the html
and class in a local server, I usually can get all params sucessfully on a P4
1.8GHz box, but only get 2000~3000 params on a 450MHz sparc. If I store them in
a outside server, I can only get 300~800 params every time depends on network
Kyle, any chance of an actual functioning testcase?  Like the compiled java
bytecode plus the generated HTML pointing to it, all in a nice zip file soit can
just be downloaded, decompressed, and loaded in the browser?  It should compress
quite nicely...

The basic issue, I suspect, is that someone is calling BeginUpdate(), so we
flush out the data as it exists at that point.  The question is who's calling
BeginUpdate, and it would be pretty simple to answer with a usable testcase.
The same testcase works fine with appletviewer. I'm looking into the java source
code to see how getParameter() gets implemented.
the problem is likely in mozilla side. If I inserted a printf after this line:
I found the total number of params was already wrong at that time.
Attachment #142985 - Attachment mime type: application/octet-stream → application/zip
OK.  So the problem seems to be that a reflow event that we post (probably when
we open the body) puts us in PresShell::ProcessReflowCommands, which manually
flushes out all pending notifications.

Given that and the various other codepaths that can result in FlushTags() being
called in the middle of an <object>/<applet>, I think the right course of action
is to simply not append such nodes to the document until we see the end tag
(like we do for scripts in the XML content sink).  Will that break anything? 
Can one put script with document.write() calls inside <applet>?  If so, we can't
do what I propose and instead need to look at ways to prevent content flushing
while mInMonolithicContainer is true....
-> Layout per comment 12.
Component: Java: OJI → Layout
Assignee: kyle.yuan → nobody
QA Contact: avm → core.layout
I'd really like to say that i think we should just wait with inserting the
<applet> until we reach the </applet>-tag, in fact the code in XML-sink was
designed to support things like that.

Unfortunatly I don't think we can do that since it would break pages like:

  <script>document.write('<param name=foo value=bar>');</script>
  <param name=otherParam value=dummy>

Since the <script> wouldn't be executed until we close the applet, which means
that the data would be written to the wrong place...

Oh, how I hate document.write...
I'm experiencing the same problem on the menu applet on using 
various version of Mozilla with various version of Java Sun Plugins and various 
version of Linux and Windows.

I've deeply tested the java applet and seems that Mozilla sometimes try to 
render the applet before loading all parameters. This happens more frequently 
if the applet has a large number of parameters and the connection is slow.

This bug seems related to the 145979 bug.
Blocks: 145979
Blocks: 242733
*** Bug 145979 has been marked as a duplicate of this bug. ***
Depends on: 144072
Depends on: 239152
roc suggested just not instantiating the plugin if DoneCreatingElement() has not
been called on the node yet (and notifying the frame when it gets called).

That may be the simplest and cleanest solution to this bug...  One that could
even be done for 1.7, I think.
Keywords: helpwanted
DoneCreatingElement only gets called on a few node types and it gets called as
soon as the tag is parsed. We need something else.
Argh.  I was thinking about the post-bug 239152 world.

As it is, we could add a DoneAddingChildren hack like <textarea> and <select>
do... :(
That is exactly what I have done. In fact I've unified those hacks into a couple
of methods in nsIContent.
Attached patch attempt #1 (obsolete) — Splinter Review
Here we go. The patch looks big but it's actually quite simple (although bigger
than it needs to be, I suppose, because of the cleanup that I did).

-- make all NS_NewHTML...Frames take an aFromParser parameter, because that
makes the content sink a bit simpler
-- add DoneAddingChildren/IsDoneAddingChildren methods on nsIContent, only
meaningfully implemented in textareas, applets, objects and selects; if an
element is not created by the parser, then it is always 'done adding children'
-- remove those methods from nsITextArea/nsISelect
-- nsObjectFrame checks that the children are done, or else it refuses to
instantiate the plugin
-- if the applet and object elements detect that children are done, they
recreate all their frames (if any). Normal case is there aren't any frames yet.
It would be slightly more efficient to existing frames, but that seems harder
to do from content. It might be slightly safer too, but it *looks* OK to do the
frame recreation from the sink callback.

Now, with this patch, things still seem to generally work, and I can use Flash
plugins. But I can't get Java to work here at all in any build with or without
the patch, so I can't test Java, and I can't see if the test is fixed. Not sure
why. doron, want to take it for a spin?
Assignee: nobody → roc
I crash on windows and linux with the java plugin installed - on windows, I
can't get a stack.  Going to see if linux is better.
I think this is because I forgot to include a file in the patch! sorry! I'll
post a new patch.
Attached patch attempt#2Splinter Review
Sorry, I changed a file in parser and forgot to put it in the diff ... probably
because I never change files in parser :-)
Attachment #149486 - Attachment is obsolete: true
I treid the patch and it indeed seems to fix the problems we have seen.  

Nominating this as a 1.7 blocker, as this affects Java-using corps like IBM and
Sun :)

Who would be the right people to review this?
Flags: blocking1.7?
OS: Linux → All
Comment on attachment 149541 [details] [diff] [review]

Boris can review this.
Attachment #149541 - Flags: superreview?(bzbarsky)
Attachment #149541 - Flags: review?(bzbarsky)
I'll try to get to this before Thurs evening, but if that doesn't happen then it
won't happen till Monday (I'm gone all weekend).
Comment on attachment 149541 [details] [diff] [review]

Drive-by review comment:

+  virtual void IsDoneAddingChildren(PRBool* aIsDone)

This should be:

+  virtual PRBool IsDoneAddingChildren()
I was trying to resist deCOMtaminating that, but sure, I can do it :-)
Comment on attachment 149541 [details] [diff] [review]

+  nsHTMLTextAreaElement(nsINodeInfo *aNodeInfo, PRBool aFromParser);
   nsHTMLTextAreaElement(nsINodeInfo *aNodeInfo);

How about adding an argument to the existing constructor with a default value
in stead of adding a whole new constructor?

r+sr=jst with that, and my drive-by review comment addressed.
Attachment #149541 - Flags: superreview?(bzbarsky)
Attachment #149541 - Flags: superreview+
Attachment #149541 - Flags: review?(bzbarsky)
Attachment #149541 - Flags: review+
good idea. I'll do that.
checked into trunk. leaving the bug open for possible branch checkin.
I think this reduced Tp on btek :-)
Sweet! :-)
Comment on attachment 149541 [details] [diff] [review]

I tested it on both Solaris & Linux, it works like a charm. Thanks for fixing
this. Should we ask for approval1.7?
Comment on attachment 149541 [details] [diff] [review]

a=mkaply for 1.7
Attachment #149541 - Flags: approval1.7+
The branch backport of this is tricky because of some refactoring that jst did
in 1.8a1.
Attached patch branch patch (obsolete) — Splinter Review
Here's the backport. Someone with a full branch checkout needs to build, test,
and check in this patch.
I'll test this on linux 1.7 branch today.
Flags: blocking1.7? → blocking1.7+
No longer blocks: 145979
You use:

+  return mDoneAddingChildren;

yet you define it as:
+ virtual void IsDoneAddingChildren(PRBool* aIsDone);

I changed the definition to match the implementation and it compiled, I assume
that is what you meant?
Attachment #149829 - Attachment is obsolete: true
Attachment #149928 - Attachment is obsolete: true
Looks good. Check it in.
Whiteboard: fix ready to land
*** Bug 237657 has been marked as a duplicate of this bug. ***
did this get checked in?  can it be marked fixed?
I had to back out from 1.7 because of a mistake checking in.

It will go in again in an hour or so and then I will close it.
It looks like mkaply landed this on the 1.7 branch 2004-06-04 08:30 -0700.  Has
it landed on the trunk as well?  Should this now be marked FIXED and fixed1.7?
Closed: 17 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Whiteboard: fix ready to land → needed-aviary1.0
I'll put this in aviary since there is a tiny correction to doron's patch (not
code related)
Whiteboard: needed-aviary1.0 → fixed-aviary1.0
Depends on: 585153
You need to log in before you can comment on or make changes to this bug.