My favorites | Sign in
GWT
Project Home Downloads Wiki Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1159: REGRESSION: 1.4.10RC: UIObject.sinkEvents no longer works on UIObjects that aren't Widgets
1 person starred this issue and may be notified of changes. Back to list
 
Reported by sandy...@gmail.com, Jun 4, 2007
Found in GWT Release:
1.4.10RC

Detailed description:
I have some more advanced Widgets where only part of them should receive
click/mouse events. I've structured the code so the DOM elements that
should be clickable are represented by UIObjects and the UIObjects
sinkEvents that the Widget listens for.

I'm attaching an example project that displays two simple custom widgets
designed to demonstrate this behavior. One widget sinks events on a child
UIObject element, the other on the Widget itself. If you run the project
under GWT 1.3 both widgets work fine, under 1.4.10RC only the one that
sinks events on the widget works. There is compiled output from 1.3.3 and
1.4.10 included in the zip.


Workaround if you have one:
Only call sinkEvents on the parent Widget. This has a negative performance
 effect, eg: many mouse move events being fired for parts of the widget
that don't care about mouse moves that now have to be processed and inspected.

Links to the relevant GWT Developer Forum posts:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_frm/thread/cf47c0b2a9d6fac5/9d76327c7619f66f

GWTSinkEvents.zip
155 KB   Download
Jun 5, 2007
#1 sandy...@gmail.com
After more discussion on the groups I realized this break was intentional and the
original issue likely won't be "fixed".

I would suggest the release notes are updated.

Also consider another related breaking change of moving UIObject.sinkEvents to
Widget.sinkEvents. This would likely only affect people who are already affected by
the change and make the API more correct.
Jun 6, 2007
#2 gwt.team...@gmail.com
Documentation update...
Owner: gwt.team.jgw
Labels: -Priority-Medium Priority-Critical Category-UI Milestone-1_4_RC2
Jun 12, 2007
#3 gwt.team...@gmail.com
(No comment was entered for this change.)
Status: Accepted
Jun 19, 2007
#4 gwt.team...@gmail.com
(No comment was entered for this change.)
Status: Started
Jul 11, 2007
#5 gwt.team...@gmail.com
(No comment was entered for this change.)
Status: ReviewPending
Jul 22, 2007
#6 gwt.team...@gmail.com
(No comment was entered for this change.)
Labels: ReviewBy-bruce ReviewBy-knorton
Jul 24, 2007
#7 gwt.team...@gmail.com
Fix committed as r1265.
Status: FixedNotReleased
Aug 3, 2007
#8 gwt.team...@gmail.com
jgw's commit log to clarify the change:

The original behavior of DOM event sinks was that any element on which you
called sinkEvents() would have its events dispatched to the 'nearest listener',
as defined by DOM.setEventListener(). In practice this is always the Widget
that 'owns' that element. As Sandy points out, this is actually quite useful
behavior, because it allows you to sink specific events on sub-elements, but
not on the Widget's root element -- which means that onBrowserEvent() will be
called much less often in some instances.

I originally pulled this dispatch code out because I thought it was a leftover
that wasn't intended to be there in the first place. That was an overzealous
mistake on my part, and it turns out this behavior was actually specified in
the DOM.sinkEvents() method:

> Sets the current set of events sunk by a given element. These events will be
> fired to the nearest {@link EventListener} specified on any of the element's
> parents.

I also went ahead and added DOM.eventGetCurrentTarget(), which can useful when
the listener and the current target can be different.

Aug 20, 2007
#9 gwt.team...@gmail.com
1.4 RC2 now released.
Status: Fixed
Apr 28, 2008
#10 sumitcha...@google.com
 
Owner: jgw
Feb 8, 2011
#11 rjrjr@google.com
(No comment was entered for this change.)
Labels: -Milestone-1_4_RC2 Milestone-1_4-RC2
Sign in to add a comment

Powered by Google Project Hosting