- We added a method to NodeImpl called allChildrenParsed(). The
default implementation does nothing, but on HTMLAppletElementImpl, it
sets a flag. I didn't want to add a flag to NodeImpl because it saves
memory, and different node/element types may want to handle this
differently.
- allChildrenParsed() is called from KHTMLParser::processCloseTag()
(so we're guaranteed to at least have all child nodes present in the
source document).
- RenderApplet::createWidgetIfNecessary() refuses to create the widget
until its element's children have been parsed
(HTMLAppletElementImpl::haveParsedAllChildren()).
- HTMLAppletElementImpl::allChildrenParsed() calls setNeedsLayout() on
its renderer. This will end up triggering a successful call to
RenderApplet::createWidgetIfNecessary(). The applet is then loaded
with the correct set of parameters.
Is this a "good" way to fix the bug? How would you do it?
I can provide a patch upon request.
Thanks,
-Tim Omernick
Engineer, The Omni Group
On Sep 7, 2004, at 5:11 PM, Tim Omernick wrote:
WebCore devs,
We've recently discovered an issue with WebCore v125's
RenderApplet::createWidgetIfNecessary() which affects both Safari 1.2.3
and OmniWeb 5. If it's called before the applet element's children are
parsed, then only those parameters which have been parsed will be used
when creating the the Java plugin.
The KHTML code doesn't appear to have this problem, since it resets the
applet's parameters on each call to RenderApplet::layout().
Unfortunately, there doesn't appear to be any way to similarly set
parameters on an applet in Apple's Java plugin.
What do you suggest we do? One potential solution would be to refuse
to create the applet until all of its child param elements are parsed,
but that seems a little kludgy.
Here's a CGI script which demonstrates the problem by sending part of
an applet's params, waiting 10 seconds, and then sending the rest.
[demime 0.98b removed an attachment of type application/octet-stream
which had a name of delayed-applet-parameters]
The applet is on the right side of the page.
Thanks,
-Tim Omernick
Engineer, The Omni Group
_______________________________________________
webcore-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webcore-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webcore-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webcore-dev/email@hidden