The backtrace shows that both the mouseover and mouseout are coming
from the <html> sprite's clickdiv.
[I added detailed information to the bug report.]
On 2009-08-13, at 14:43EDT, Max Carlson wrote:
Yes, it makes sense. See lps/components/extensions/html.lzx for the
handoff - the view:
LzMouseKernel.disableMouseTemporarily();
Maybe that call should prevent the next onmouseout event from being
sent?
The next thing that happens is the mouse leaves the iframe and
mouses over the canvas container div (see the LzSprite constructor
for the canvas - isroot == true). If the mouse goes over an element
inside the app, LzMouseKernel.__resetMouse() is called to restore
clickability.
You might try running with backtrace on to see where the spurious
onmouseover event is being fired from...
P T Withington wrote:
Does this theory make sense? Where should I be looking to see how
mouse events are transferred from a view's clickdiv to the actual
div?
It seems plausible to me that what might be happening here is that
the mouse enters the iframe's clickdiv and it gets a mouseover
event, but that event turns off the clickdiv hierarchy, so you can
interact with the iframe content, and so the browser sends a
mouseout event (because the mouse has effectively left the
building). I need to understand better how the mouse events are
transferred from the clickdiv to the view content.
[[#LPP-8375] onmouseout even on HTML component is firing
onmouseover, not onmouseout - OpenLaszlo Jira](http://jira.openlaszlo.org/jira/browse/LPP-8375
)
--
Regards,
Max Carlson
OpenLaszlo.org
