79268 - Java applet is told the wrong size.

Status: RESOLVED INVALID

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Xuân Baldauf]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010506
BuildID:    2001050620

There seems to be a minimum size for an applet 112x27 pixels, at least as a
relict somewhere in the java implementation code. A java applet can ask its own
size by calling java.awt.Applet.size() or java.awt.Applet.getSize(new
Dimension()). That size is composed of a width and a height. Web developers can
make their applets have any size using WIDTH and HEIGHT parameters of the
APPLET-Tag. But when the applet asks its own width, the maximum of the real
width and 112 pixels is returned. Likewise, for the height, the maximum of the
real height and 27 pixels is returned.

The bug only affects the internal representation of the size of the applet, but
not the applet's visual size. It's visual size is as expected by the web page
author. Pixels which seem to belong to the user interface area, but do not, are
simply clipped.

Reproducible: Always
Steps to Reproduce:
1. With the Java Plugin enabled, go to
"http://justchat4.medium.net:4000/chat/test/mozilla/java/JavaAppletSize.html".
The applets size is set to 50x20 pixels in the HTML sourcecode.
2. Open the Java Console window.
3. Look at the size report the applet sees.

Actual Results:  You will see

this.size()=java.awt.Dimension[width=112,height=27].

Expected Results:  You should see

this.size()=java.awt.Dimension[width=50,height=20].

This bug does not happen in Opera 5, which also uses the Java Plugin. That leads
me to the conclusion that this bug is more a mozilla bug than a java plugin bug.

"Severity" is on "major", because many applets need to know their own size in
order to render their content properly.

Comment 1

[Igor Kushnirskiy]

moving to oji

Comment 2

[edburns]

Reporter, may I have the source for the applet?

Comment 3

[edburns]

Excellent report, reporter.  Regarding your Opera5 comment, The Java Plugin 
that runs in Opera 5 is a Netscape 4.x style plugin, while the one that runs in 
mozilla is a Mozilla XPCOM plugin.  The two have very little code in common.

Comment 4

[edburns]

I do see this with the java plugin.  Accepting

Comment 5

[Xuân Baldauf]

Hello evaluator :-)

The source is:

package com.mn.tools.test.bugs.mozilla;

import java.applet.Applet;
import java.awt.*;

public class AppletSize extends Applet {

	public void start() {
		System.out.println("this.size()="+this.size()+".");
	}
}

Comment 6

[edburns]

I have filed Sun internal bugtraq bug 4459064.  It appears this is not in OJI:

I modified my local copy of java.applet.Applet to print out the re-size values 
and a stack trace.  It appears to come from java.awt.Component.  Re-assigning 
to Stanley.  Stanley is there a workaround?

Trace level set to 2: basic, net ... completed.
debug: edburns: setWindow start: width: 50 height: 20
Registered modality listener
debug: edburns: setWindow end: this.width: 50 this.height: 20
Referencing classloader: sun.plugin.ClassLoaderInfo@18c56d, refcount=1
Added trace listener: sun.plugin.navig.win32.AppletPluginPanel
[com.mn.tools.test.bugs.mozilla.AppletSize,0,0,112x27,invalid,layout=java.awt.Bo
rderLayout]
Sending events to applet. LOAD
Sending events to applet. INIT
Sending events to applet. START
Determine if the applet requests to install any HTML page
HTML Installation finished.
Determine if the applet requests to install any JAR
Jar cache option: null
Jar archive(s): null
Jar cache version(s): null
Applet Installation finished.
debug: edburns: Applet.resize(50, 20)
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Unknown Source)
	at java.applet.Applet.resize(Applet.java:155)
	at java.applet.Applet.resize(Applet.java:169)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
debug: edburns: AppletViewer.getViewedObject : java.awt.Dimension
[width=50,height=20]
debug: edburns: Applet.resize(112, 27)
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Unknown Source)
	at java.applet.Applet.resize(Applet.java:155)
	at java.applet.Applet.resize(Applet.java:169)
	at java.awt.Component.setSize(Unknown Source)
	at sun.plugin.AppletViewer$1$AppletEventListener.appletStateChanged
(AppletViewer.java:431)
	at sun.applet.AppletPanel.dispatchAppletEvent(Unknown Source)
	at sun.applet.AppletPanel.appletResize(Unknown Source)
	at java.applet.Applet.resize(Applet.java:158)
	at java.applet.Applet.resize(Applet.java:169)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
debug: edburns: AppletViewer.getViewedObject : java.awt.Dimension
[width=112,height=27]
this.size()=java.awt.Dimension[width=112,height=27].

Moving Severity to minor since HTML authors have been dealing with this problem 
for a long time.  The workaround is to know that applets can't be smaller than 
112 x 27 pixels.

Comment 7

[Xuân Baldauf]

<quote>
Moving Severity to minor since HTML authors have been dealing with this problem 
for a long time.  The workaround is to know that applets can't be smaller than 
112 x 27 pixels.
</quote>

Severity minor is okay, but I do not agree with your reason. Since the first 
somewhat usable milestone of mozilla, I have been waiting for a fix (with the 
assumption that many people suffer the same bug). Maybe my assumption is wrong, 
but just waiting for a bug to be fixed does not make it have a workaround.

Imagine a stock ticker applet or the like, which is about 15..20 pixels high. 
How should a workaround emerge by just knowing the bug? ;-)

Thank you for digging into the bug. Maybe the JavaPlugin tries to set a default 
size and does so too late.

Comment 8

[edburns]

Reporter, the SUN engineer working on this bug has closed it as non-
reproducible.  Please contact them if you disagree <[e-mail]>.

Comment 9

[edburns]

This bug is not reproducible in 1.4 Beta. 

Upon investigating 1.3.1, this bug only happens in Win32 environment when 
applet's width is less than 112. 

Width 112 appears the value of ::GetSystemMetrices(SM_CXMIN) and enforced 
inside native call reshapeFrame (awt_windows.cpp) through 
java.awt.Component.reshape method.


-----------------------------------------------------

I ran into this bug while doing a random survey of
internet applet behavior in Mozilla.

I ran into several applets where the applet was
relatively small horizontally (e.g. 80 pixels) and
where the text was truncated or off center.

After some digging, I discovered this was due to the
applet being given the wrong width.  e.g. 112 rather than 80.

I am adding a sample HTML file and Java Applet as attachments.

The bug is still present in Merlin b73.

This is a bug that seems likely to interfere with a lot
of standard internet applets.  We should consider fixing this
in the Ladybird patch train.

graham.hamilton@Eng 2001-07-28

The bug is caused by enforcing Windows treshold (Windows system metrics 
SM_CXMIN and SM_CYMIN) values in awt_Window.cpp. That means any awt frame can 
not be smaller than SM_CXMIN x SM_CYMIN, which is 112 x 27.

zhengyu.gu@east 2001-07-30

OK, it looks like awt_Window.cpp is applying limits that
are intended for genuine free standing frames.

However, the Java Plug-in is running each applet in an
embedded frame and the SM_CXMIN x SM_CYMIN sizes don't
make sense there and break applets.  The applet thinks it
is getting the SM_CXMIN x SM_CYMIN area, but the containing
browser is really assigning it a much smaller area.

It looks as though the fix might be to check the p->IsEmbedded()
status and only use SM_CXMIN x SM_CYMIN if we are not an embedded frame.

graham.hamilton@Eng 2001-07-31