I've been working on some improvements and realized there's a subtle design mistake for how mouse up, down, and move events work. The current implementation checks whether a mouse event is within the bounds of an element before calling the mouse-whatever protocol. Really, it should be up to the element if its bounds influence how it responds to mouse events. I've created a local branch that fixes the issue. In practice, the change shouldn't require any code changes to existing apps and that seems to be the case for all the local apps I've tested. The only edge case where it would make a difference is when creating a new element that: • implements some of the mouse-* protocols • should not respond to mouse events outside of its bounds • its parent's bounds are larger than its own bounds (or else its parent would ignore the event). Just posting here in case anyone has interest, thoughts, or questions.

One benefit of this change is that it addresses the problem where the view function passed to skia/run or java2d/run doesn't even receive mouse events for points that are within the bounds of the window, but outside the bounds of the current view. The default behavior for ui/on-mouse-down will continue to only call the on-mouse-down callback if the click is within the child element's bounds (both for backwards compatibility as well as it's probably the expected behavior), but I would also like to add a similar builtin element that doesn't check bounds. I don't know what to call it though. on-mouse-down-raw, on-mouse-down+, on-mouse-down* all seem clunky, but to be fair, it's unlikely to be useful outside of attaching mouse events to the root of view returned by a view function. I think I'm leaning towards on-mouse-down-raw.