I'm still plugging away at getting HtmlUnit to grok OPS, and seemed to hit a deadlock (c.f.
http://www.nabble.com/Javascript-error-when-using-HtmlUnit-to16153154.html#a16153154) but it's turned out to be an infinite loop! I was able to use tracing from the HtmlUnit Javascript processing code to figure out what particular Javascript was being executed over and over, and I finally found the problem.
Note that this is using OPS 3.6. The bug seems to still be in 3.7, but the Yahoo files have been restructured, so these references won't apply.
The culprit is in container.js at line 3327, namely a function called YAHOO.widget.Panel.prototype.configzIndex. At 1411, this function is set to handle any change events on the given panel object, and what I found is that this handler was being called over and over, at roughly 15ms intervals.
In that handler, at line 3339, setProperty() is called without specifying the "silent" parameter... and thus setProperty() manually fires the event handler! Yet we are already *in* the event handler. So it keeps triggering itself. When I added the third argument of "true" the problem stopped.
Now, the odd thing is browsers are probably ALSO stuck in this loop, but I suspect they use multiple threads, and so you don't really notice. If someone has a setup for debugging the Yahoo libraries in a live browser, I'd be interested to see if they could use a stub or a breakpoint to determine if they see the same behaviour.
I know this isn't an OPS issue, but... I thought this would be the place to start. Meanwhile, anyone have a link to the Yahoo folks responsible for this library? I can report it there, too.
Cheers!
rodney
p.s. Sadly, once I got past this, HtmlUnit still doesn't seem to work with OPS, but at least it takes me back to where I was before upgrading HtmlUnit...
Locked
