Joel, I did a quick test in Safari 3 on Mac and things appear to work well, including scroll. I haven't tested all platforms, so I'm assuming for the moment they work and that both scroll and zoom are non-breaking features :)
Thanks for digging that deep deep rabbit hole. Fred On Tue, Mar 17, 2009 at 2:50 PM, Joel Webber <j...@google.com> wrote: > 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 <fre...@google.com> 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 <j...@google.com> 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 >> fre...@google.com >> >> > -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
