We recently fixed a similar issue for the <object> element. Basically
we overrode childrenChanged() and marked the widget as needing an
update. This does mean that we'll effectively recreate the plugin if
the parameters change (or if they take a long time to come in), but in
the typical case we do just fine.
Thank you for the reply, Dave :-)
I considered that, but I thought it would be awfully distracting to the
user. But, you're right -- in the typical case, it either won't happen
or the user won't notice.
Post-125, we actually eliminated the close() function (which was
effectively the allChildrenParsed call that you added), and so I'd
like to avoid introducing that back into the tree (given that
technically dynamically changing the parameters should work, and so
there really shouldn't be any difference between the parsing case and
the dynamic DOM case).
Yeah, I don't intend to have these changes integrated into the tree --
we were just hit particularly hard by this bug and so we had to make an
immediate fix (I think we lay out more frequently than Safari does).
If this works better in post-125 builds, then I'm all for removing my
fix and using your stuff.
Are you actually seeing a real-world page where the applet layout
happens while the parameter tags are still being parsed? Do you have
some applet with an enormous <param> list or something?
Yes, and yes. I can get it to happen fairly reliably at
http://www.rgs.org/ -- the applet on the right side of the page will
sometimes fail to load completely and report an error. This happens in
both Safari and OmniWeb 5.1, more frequently on a slow connection.
-t
_______________________________________________
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
