[icedtea-web] RFC: fix null dtd for swing applications rendering html

[Dr Andrew John Hughes]

On 10:12 Thu 28 Oct     , Omair Majid wrote:
> On 10/28/2010 09:42 AM, Dr Andrew John Hughes wrote:
> > On 09:36 Wed 27 Oct     , Omair Majid wrote:
> >> On 10/26/2010 06:58 PM, Dr Andrew John Hughes wrote:
> >>> On 16:57 Tue 26 Oct     , Omair Majid wrote:
> >>>> Hi Deepak,
> >>>>
> >>>> Thanks for taking a look at this!
> >>>>
> >>>> On 10/26/2010 04:33 PM, Deepak Bhole wrote:
> >>>>> * Omair Majid<omajid at redhat.com>    [2010-10-26 15:46]:
> >>>>>> There has been a regression in netx: applications that render html
> >>>>>> (using Swing components) now fail with a null pointer exception.
> >>>>>> This problem can be reproduced by running the program at [1].
> >>>>>>
> >>>>>
> >>>>> What caused this regression? I thought all the app context stuff was
> >>>>> still disabled, with just the support added on the side?
> >>>>>
> >>>>
> >>>> The regression itself was caused by having security dialogs in one
> >>>> AppContext and the actual application in another AppContext.
> >>>>
> >>>> The AppContext stuff is enabled and working (in fact, some of the
> >>>> AppContext code was part of the original import of Netx into IcedTea and
> >>>> has been active ever since - most of my recent patches are about
> >>>> enabling it in the plugin case too and using AppContext correctly to
> >>>> gain its benefits). It is what allows multiple applets to have their own
> >>>> look and feels and allows security dialogs to always use the system look
> >>>> and feel without setting the look and feel of applets (or jnlp
> >>>> applications) too. I thought I had made it pretty explicit in my patches
> >>>> and changelogs :(
> >>>>
> >>>> What is still disabled is allowing applets/applications to access their
> >>>> individual EventQueues. This is because of a security patch that has
> >>>> been recently been committed to OpenJDK7. This patch provides some
> >>>> additional API and says (and I am paraphrasing): "here is some API that
> >>>> allows the proprietary plugin to check if AWT events are generated by
> >>>> the system". I dont know how to make use of it, so I havent added code
> >>>> to allow applets to access their EventQueues. At least one application -
> >>>> a swing demo, no less [1] - fails without this.
> >>>>
> >>>
> >>> Do you have a link to this patch?  We should probably backport it.
> >>>
> >>
> >> The changeset is at
> >> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/8022709a306d. Unfortunately,
> >> aside from the patch itself, there is no other documentation about it
> >> and none of the bugs are public :(
> >>
> >
> > Nothing new there then...
> >
> > We can backport this to IcedTea.  I think we should push for this to be made
> > a public API if it's generally useful for the plugin, as otherwise we're relying
> > on SunToolkit (again).
> >
> 
> Yup, I was going to backport this to icedtea6 as soon as I figured out 
> how to use it.
> 
> As for making it public, even the original developers agree: "this 
> information could be useful to more clients and probably should be 
> formalized in the public API" (second hunk in SunToolkit.java). I am not 
> sure on how the process for making an API public works, but if it is 
> possible we should be looking at making a few more APIs public too.
> 

We bug them on awt-dev to do it.  It can't happen in 6 but could still go in 7 AIUI.

If we can show that it would be useful to us as well, that would give them a reason to add it.

> Cheers,
> Omair

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8