Unfortunately, the problem ended up being even hairier than I thought. My great little scheme of using Event.currentTarget to determine the "sane" element to measure mouse coordinates relative to, turned out to be not so great after all. It turns out that the current target for captured events is actually the window, which was breaking dialog boxes, and also Fred's drag & drop code. John and I took a look at it at my desk, and came to the conclusion it would be far saner to hang a "relative element" from the DomEvent object (as a sibling field to its NativeEvent), and maintain it in the same way. This allows the caller of DomEvent.fireNativeEvent() to specify this element explicitly. In the case of Widget.onBrowserEvent(), it simply passes its root element along, which will mimic the old MouseListener behavior precisely.
@Fred: This also fixes the scroll-relative coordinates issue. I just created a code review here: http://gwt-code-reviews.appspot.com/13803 On Tue, Mar 17, 2009 at 4:03 PM, Fred Sauer <[email protected]> wrote: > Joel, > The null problem is gone. However, with JOEL_PATCH = true, the > event.getX/Y() coordinates are off when the document is scrolled. Launch the > DragDropDemo with the window less that full size, scroll the document down a > bit, then try dragging a red box. You'll notice that the box stays in place > on mouse down, but jumps once you start dragging. If you set JOEL_PATCH = > false then the coordinates work. > > Fred > > > On Tue, Mar 17, 2009 at 12:51 PM, Joel Webber <[email protected]> wrote: > >> Fred & John, >> Would you guys mind having a quick look at this miniscule patch? It's very >> simple, so I just attached the diff inline. >> >> Background: Fred discovered some pretty odd behavior in his drag & drop >> library against 1.6, and we tracked it down to a difference between Safari 3 >> & 4 (!). It turns out that on Safari 3, Event.currentTarget can actually be >> null when it should be returning the Window object. Safari 4 fixes this, and >> behaves the same way as Firefox. This patch just causes it to return $wnd >> whenever Event.currentTarget resolves to null. This seems to fix Fred's >> issue, and to my knowledge explains the behavior perfectly (@Fred, if you >> could confirm this, that would be quite helpful). >> >> Thanks, >> joel. >> >> Index: user/src/com/google/gwt/dom/client/DOMImplSafari.java >> =================================================================== >> --- user/src/com/google/gwt/dom/client/DOMImplSafari.java (revision 5016) >> +++ user/src/com/google/gwt/dom/client/DOMImplSafari.java (working copy) >> @@ -48,6 +48,11 @@ >> } >> >> @Override >> + public native EventTarget eventGetCurrentTarget(NativeEvent event) /*-{ >> + return event.currentTarget || $wnd; >> + }-*/; >> + >> + @Override >> public native int eventGetMouseWheelVelocityY(NativeEvent evt) /*-{ >> return Math.round(-evt.wheelDelta / 40) || 0; >> }-*/; >> >> >> > > > -- > Fred Sauer > Developer Advocate > Google Inc. 1600 Amphitheatre Parkway > Mountain View, CA 94043 > [email protected] > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
