| 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 |
Sign in to add a comment
|
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
|
|||||||||||||||||||||
,
Jun 05, 2007
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 06, 2007
Documentation update...
Owner: gwt.team.jgw
Labels: -Priority-Medium Priority-Critical Category-UI Milestone-1_4_RC2 |
||||||||||||||||||||||
,
Jun 12, 2007
(No comment was entered for this change.)
Status: Accepted
|
||||||||||||||||||||||
,
Jun 19, 2007
(No comment was entered for this change.)
Status: Started
|
||||||||||||||||||||||
,
Jul 11, 2007
(No comment was entered for this change.)
Status: ReviewPending
|
||||||||||||||||||||||
,
Jul 22, 2007
(No comment was entered for this change.)
Labels: ReviewBy-bruce ReviewBy-knorton
|
||||||||||||||||||||||
,
Jul 24, 2007
Fix committed as r1265.
Status: FixedNotReleased
|
||||||||||||||||||||||
,
Aug 03, 2007
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
1.4 RC2 now released.
Status: Fixed
|
||||||||||||||||||||||
|
,
Apr 28, 2008
Owner: jgw
|
||||||||||||||||||||||
 Sign in to add a comment
|
||||||||||||||||||||||
