http://gwt-code-reviews.appspot.com/635802/diff/1/3 File user/src/com/google/gwt/user/client/Event.java (right):
http://gwt-code-reviews.appspot.com/635802/diff/1/3#newcode556 user/src/com/google/gwt/user/client/Event.java:556: DOM.sinkEvent((com.google.gwt.user.client.Element) elem, type, sink); I'm not 100% sold on the idea of this method. The alternative would be to simply continue defining event bits for all the new events we can find. But I was also kind of hoping to get an "escape hatch" that would allow people to use new events as they become available, rather than waiting on us to add new bits and push a new GWT version. http://gwt-code-reviews.appspot.com/635802/diff/1/4 File user/src/com/google/gwt/user/client/impl/DOMImpl.java (right): http://gwt-code-reviews.appspot.com/635802/diff/1/4#newcode130 user/src/com/google/gwt/user/client/impl/DOMImpl.java:130: sinkEvent(elem, eventGetType(bit), (bits & bit) != 0); We have to route sinkEvents(bits) through the new sinkEvent(string) because it's pretty much the only way to ensure that the two sink methods play well together. I think it would be a Bad Thing to have the same event sunk twice, because it would create potentially hard-to-debug situations where you're receiving events twice in onBrowserEvent(). The downside is that this is pretty inefficient because of all the non-inlineable layers of indirection, the added "__events" map, and the extra work going on in Element.addEventListener(). A simpler, more efficient, but slightly confusing alternative would be to keep sinkEvent() and sinkEvents() completely separate, and let people know that if they use both for the same event, they'll just get duplicate events. Then create event bits for the current well-known event types and be done with it. http://gwt-code-reviews.appspot.com/635802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
