[gwt-contrib] Re: RR: 1.6 Event handler proposal

[Joel Webber]

I completely agree that it is important to find a better solution to the
irritating cross-browser differences in keyboard event handling, and I'd
really like to discuss that on a separate thread (starting such a thread
right now would be perfectly fine by me -- I just don't want to confuse the
issue by discussing too many things on one thread).
The goal of this design is to simplify and normalize the way that
widget-level events are structured. So we could really use feedback on the
way that events are registered and handled, the mechanism for storing and
firing sets of listeners, and the way in which new widgets use them. We're
planning on moving everything to this structure (with shims for
backwards-compatibility), so again your feedback would be helpful.

Thanks,
joel.

On Tue, Sep 23, 2008 at 2:22 AM, Emily Crutcher [EMAIL PROTECTED] wrote:

 Yep, this would be a nice utility to have available, I think we might be
 able to get the isControlKey() part fully integrated with the native events,
 as I think we've already started down that route.

 I also like the idea of a logical key event that is only fired at sane
 times if you have the bandwidth to brain storm on how to tweak your design
 to get it there.  We could, for instance have a static
 FilterKeyEvent.fireEvent method that widgets could call which create
 FilterKeyEvent's at the right time.



 On Tue, Sep 23, 2008 at 12:51 AM, Ian Petersen [EMAIL PROTECTED] wrote:


 On Mon, Sep 22, 2008 at 7:43 PM, Thomas Broyer [EMAIL PROTECTED]
 wrote:
  LGTM but...
 
  ...have the keyDown/keyUp vs. keyPress been revised? (keyPress is
  supposed to receive characters while keyDown/keyUp are keys –this
  is the same as TextEvent vs. KeyboardEvent in DOM Level 3 Events–, see
  also PPK's compatibility tables).
  In the mean time, handling keys lead to some browser-specific tweaks
  in your own code, whereas you would expect GWT to workaround those
  differences/bugs for you and give you a predictable behavior.
 
 
 http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-TextEvents-Interfaces
  http://www.quirksmode.org/dom/events/index.html#t09
  http://www.quirksmode.org/dom/w3c_events.html#keyprops
 
  See also:
  http://code.google.com/p/google-web-toolkit/issues/detail?id=72
  http://code.google.com/p/google-web-toolkit/issues/detail?id=78
 
  It would however affect issue 1566:
  http://code.google.com/p/google-web-toolkit/issues/detail?id=1566
  (just remove the ONKEYPRESS handling, but Opera doesn't repeat keydown
  events; this could be worked around specifically for Opera with a
  timer to synthetize keydown events until you receive a corresponding
  keyup event)

 I haven't been following too closely, so sorry if this is spam, but
 issue 1061 might be relevant, too.  I haven't looked at the related
 code in quite a while, but I could always revisit it if necessary.
 http://code.google.com/p/google-web-toolkit/issues/detail?id=1061

 Ian


 


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Safari Empty History Tokens

[Joel Webber]

Wow, that's about the freakiest thing I've seen in a while. The fact that
the following code fails is really disturbing:

  private static boolean isBorked() {

Element e = DOM.createDiv();

e.setInnerHTML(spoo);

return e.getInnerHTML().length() == 0;

  }


I also tried taking the History.newItem() calls out of onModuleLoad() and
performing them in response to a button click (just in case it was in a
weird state during module init), but it still does the same thing.

This might be related to issue 2909 as well. I'm working on figuring out
what's going on here, so if anyone has any ideas please speak up!
(can you tell that I really want these History issues to go away once and
for all?)

Cheers,
joel.

On Mon, Sep 22, 2008 at 12:56 PM, Sam Gross [EMAIL PROTECTED] wrote:

 By immediate history processing, I mean the changes in r3234 that include
 synchronous calls to onHistoryChanged (in addition to the timer-based
 processing).
 Removing the synchronous calls for empty tokens works around the Safari
 bug.

 I filed issue 2905 to track this bug.

 On Mon, Sep 22, 2008 at 4:24 AM, Thomas Broyer [EMAIL PROTECTED] wrote:

 On 21 sep, 23:46, Sam Gross [EMAIL PROTECTED] wrote:
  Has anyone else noticed weird behavior with Safari 3 and empty history
  tokens?  Setting the innerHTML during the invocation of the history
 listener
  for empty tokens does not seem to have any effect.

 Seems a bit weirder actually: using the previous button, go back to
 #x then forward (back to the enmpty token) and it'll show History
 OK.


 Yes - those invocations of the history listeners are due to the history
 timer - not synchronous calls in HistoryImpl#newItem.



 And it's working OK in Chrome (0.2.149.30).

  I think the problem has to do with the immediate history processing.

 Probably. Though, the immediate processing isn't precisely
 documented, so i'd say you shouldn't rely on it ;-)


 I'm not relying on immediate processing.  This bug is triggered by
 immediate history processing.


  I put a repro case at:http://web.mit.edu/sgross/www/history/Hello.html


 


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---