Closed
Bug 79268
Opened 23 years ago
Closed 23 years ago
Java applet is told the wrong size.
Categories
(Core Graveyard :: Java: OJI, defect, P3)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: baldauf--2015--bugzilla.mozilla.org, Assigned: stanley.ho)
References
()
Details
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.
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.
I do see this with the java plugin. Accepting
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 5•23 years ago
|
||
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()+"."); } }
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.
Assignee: edburns → stanley.ho
Severity: major → minor
Status: ASSIGNED → NEW
Priority: -- → P3
Reporter | ||
Comment 7•23 years ago
|
||
<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.
Reporter, the SUN engineer working on this bug has closed it as non- reproducible. Please contact them if you disagree <zhengyu.gu@sun.com>.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
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
You need to log in
before you can comment on or make changes to this bug.
Description
•