[Bug 189] New: NullPointerException due to confused OBJECT/EMBED/APPLET attributes and PARAMs
bugzilla-daemon at icedtea.classpath.org
bugzilla-daemon at icedtea.classpath.org
Mon Sep 1 17:07:05 PDT 2008
Summary: NullPointerException due to confused OBJECT/EMBED/APPLET
attributes and PARAMs
AssignedTo: unassigned at icedtea.classpath.org
ReportedBy: java at tjworld.net
This is an upstream report based on Ubuntu Bug LP #199732
== Overview ==
Loading some Java applets via Firefox and the plugin with openjdk-6 results in:
Exception in thread "main" java.lang.NullPointerException
See, for example:
I'll detail the analysis and the fix after this explanation.
== Background ==
There are an unknown number of Internet sites hosting Java applets that fail
when using the icedtea plug-in but work using the Sun Java plug-in. The reason
for the failure is usually a result of the historic mess that was made of the
HTML EMBED, APPLET, and OBJECT tags.
As a result of the various contrived work-arounds that web-site authors used to
try and ensure that all browsers managed to load a Java applet, there are many
combinations of these tags and the PARAM name/value attribute tags that attempt
to use browser quirks to ensure the user does see the Java applet.
There has never been a standard for the EMBED tag particularly, it having grown
over time from its beginnings in Netscape Navigator. There have likewise been
various unofficial extensions to the OBJECT tag - the only properly
standardised tag - which should really replace the other two tags in modern
browsers and web-applications.
As a result users often suffer, caught between a rock and a hard place when
things go wrong - such as this NullPointerException - since they have no
influence over the web-site operators in most cases, and often get told by
developers that it is the web-site's problem, not the plug-in, despite the
widespread use of varying combinations of browser-specific tag combinations.
(See, for example, the responses in Bug #151).
== The Issue ==
In the cases I've dealt with the failures are caused by the use of the EMBED
tag with no "code" attribute.
However, the HTML author has attempted to ensure all browsers/Java plug-ins
load the applet by including OBJECT and/or APPLET variations as well as using
PARAM name/value pairs.
The plug-in currently refuses to accept a tag-set passed by the browser plug-in
*before it has been completely parsed* if the initial tag isn't of the form:
<EMBED CODE="" WIDTH="" HEIGHT=""> ... </EMBED>
It will also then ignore any PARAM name/value pairs as being "outside an APPLET
tag". This is unfortunate since in many cases the PARAM pairs contain values
that the plug-in can use to load the applet successfully.
== The Solution ==
The patch I've created refines the way PluginAppletViewer.parse() deals with
the EMBED tag. It adopts the same logic as is already present for the OBJECT
tag, deferring rejection of the attributes until the closing tag, and thus
allowing any PARAM name/value pairs after the opening tag to be parsed into the
When the closing EMBED tag is parsed, if there is still no "code" or "object"
attribute, the patch makes one last attempt to locate the entry-point class. It
first looks for the attribute "classid". If it is found, the patch further
checks that the value is prefixed "java:". If so, a new "code" attribute is
created and assigned the remaining characters of the "classid" value. This will
allow the applet to start.
E.g. <PARAM name="classid" value="java:org.some.main.class"/>
If any of these attempts fail it nullifies the attributes hash and fails with
the same message as previously.
This patch allows the plug-in to work with many more combinations of OBJECT,
APPLET, and EMBED tags and improves the user experience and perception of
openjdk and icedtea.
== Exception Analysis ==
This bug is caused when the Java plug-in hasn't had a window registered using
PluginMain.registerWindow(), which will set PluginMain.currentWindow.
Without PluginMain.currentWindow set (it is initialised to null), when the
gcjwebplugin sends the applet the "width" message, the applet's
PluginMain.start() message-reading loop reads the width correctly, but then
tries to get the internal height property using:
int height = currentWindow.getHeight();
Because currentWindow is NULL it causes the Null Pointer Exception on line 211.
The problem is caused in PluginAppletViewer.parse(...). There are several
overloaded versions of this function but they all pass through to the
work-horse overload that takes a complete set of arguments.
In PluginAppletViewer.parse() it scans the HTML APPLET/OBJECT/EMBED tag and
extracts the attribute values. When it finds an EMBED tag it passes it to
PluginAppletViewer.scanTag(). That method is responsible for scanning the
attributes inside the EMBED tag and assigning them to the attributes Hash.
When scanTag() returns the EMBED detection-logic does some sanity checks on the
attributes to ensure it has what it needs to execute the applet successfully.
It checks for the CODE, WIDTH, and HEIGHT attributes not being null. If any one
of them is null it sets the attribute reference to null too - effectively
wiping them all out.
When the logic in PluginAppletViewer.parse() finds the closing tag </EMBED> it
checks if the attributes reference IS NOT null and if so calls
PluginAppletViewerFactory.createAppletViewer(). That in turn calls
PluginMain.registerWindow() which, as I said at the beginning, sets
But, because an attribute of the EMBED tag was missing, the attribute Hash
reference was null and so PluginMain.registerWindow() wasn't called and
PluginMain.currentWindow remained with its initialised value, which is null.
Hence the bug.
In the case of the sites here the missing attribute is "code", and you can see
the warning in the output:
Warning: <embed> tag requires code attribute.
That really should say "Error" since it is fatal.
Because the EMBED tag was not part of a W3C standard the definition of legal
parameters is hazy. It has been introduced for HTML 5 *but* will not support
the CODE attribute.
== Patch ==
Currently the patch is included in a provisional Ubuntu openjdk-6 source
It would be preferable to have it included upstream since other distributions
have bugs reported for the same issue.
The patch could easily be moved to ./patches/ in the openjdk-6 source package,
as long as it is applied after
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the distro-pkg-dev