closure-library icon indicating copy to clipboard operation
closure-library copied to clipboard

Different behavior for keypressEvent.keyCode in Chrome and Firefox

Open manoj-compro opened this issue 9 years ago • 8 comments

Although i know this feature has been deprecated but some browsers may still support it, it is in the process of being dropped.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode

Is this library supporting deprecated properties ? If yes then is should display same behavior for this property also

manoj-compro avatar Jan 21 '17 10:01 manoj-compro

Please elaborate how and what behavior is different.

mashedcode avatar Jan 21 '17 15:01 mashedcode

I am using this sample code but in returns different values in Chrome and Firefox as following

If user press ENTER chrome returns 13 and Firefox return 0 as Firefox does not support this property but I think this should be handled by library.

this.headerElement = document.getElementById("containerParent")

goog.events.listen(this.headerElement, goog.events.EventType.KEYPRESS,
    this.parentHandler, false, this);

tutorial.notepad.Note.prototype.parentHandler = function (e) {
 console.log(event.keyCode)
};

manoj-compro avatar Jan 23 '17 05:01 manoj-compro

For keypress events you should use the charCode property of a goog.events.BrowserEvent instance instead.

mashedcode avatar Jan 23 '17 10:01 mashedcode

Thanks @mashedcode I faced one more minor issue today as: checked "timeStamp" property for click and keypress events and got "undefined" as result. also checked with goog.events.BrowserEvent instance Is there any special handling for this also as i am new to google closure library.

manoj-compro avatar Jan 23 '17 11:01 manoj-compro

Event.timeStamp is not part of the patched cross browser event at the moment.

If you really need this property you could either access it via the private _event property: .event_['timeStamp'] but this will obviously throw a JSC_BAD_PRIVATE_PROPERTY_ACCESS warning if properly annotated and is generally speaking bad practice.

Or you could add it yourself and create a PR. But I don't think that there're too many use cases for this in production code.

mashedcode avatar Jan 23 '17 11:01 mashedcode

Do you have a link that explains this property - what browsers is it available under?

shicks avatar Feb 01 '17 02:02 shicks

https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp https://googlechrome.github.io/samples/event-timestamp/

manoj-compro avatar Feb 01 '17 04:02 manoj-compro

Looping back, it looks like the timeStamp property is pretty limited in terms of browser support. If there is a reasonable way to fill it in for goog.events.Event (or BrowserEvent) then I'd be open to a PR that adds it. The second link seems to suggest it's got to do with "high resolution" timestamps, which might be harder to polyfill.

shicks avatar Feb 03 '17 23:02 shicks