Re: Where should UA insert text when the focus is changed in a keypress event handler?
Ryosuke Niwa rn...@webkit.org skreiv Tue, 20 Mar 2012 18:54:11 +0100 We're trying to figure out inside which element the editing operation must be done when a keypress event handler changes the focused element / selection for https://bugs.webkit.org/show_bug.cgi?id=81661. Should it be done at wherever focus is after keypress event is dispatched? Or whatever keypress event's target was? FWIW, Opera does #1 - inserts character in the newly focused input. I recall bugs where typing bank account numbers/pin codes and such on pages where a script changed focus automatically failing, so I believe that compatibility problems has shaped our implementation. This doesn't mean we'll never change it again, but it does mean we will thread carefully.. According to a fellow WebKit contributor, WebKit and Internet Explorer use the current focused element whereas Firefox uses the event target. This statement is a bit confusing because I have a few tests here where Chrome uses the event target.. :-o so it's WebKit and Gecko versus Trident and Presto in terms of behaviour. data:text/html,input autofocus onkeypress=i2.focus()input id=i2 Typing a character inserts the character in the first input even though focus is changing. -- Hallvord R. M. Steen Core tester, Opera Software
Where should UA insert text when the focus is changed in a keypress event handler?
Hi, We're trying to figure out inside which element the editing operation must be done when a keypress event handler changes the focused element / selection for https://bugs.webkit.org/show_bug.cgi?id=81661. Should it be done at wherever focus is after keypress event is dispatched? Or whatever keypress event's target was? DOM level 3 events doesn't seem to specify this behavior: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress According to a fellow WebKit contributor, WebKit and Internet Explorer use the current focused element whereas Firefox uses the event target. Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Where should UA insert text when the focus is changed in a keypress event handler?
With my web developer hat on, I would expect the WebKit/IE behavior. Keypress is fired before the DOM is modified (I tested in Gecko and WebKit on an input element). As such, I'd expect focus changed during a keypress event to change where the text is inserted. Notably, Gecko does the WebKit/IE behavior if you use keydown instead of keypress. I don't see any reason keypress should be different from keydown. On Tue, Mar 20, 2012 at 10:54 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi, We're trying to figure out inside which element the editing operation must be done when a keypress event handler changes the focused element / selection for https://bugs.webkit.org/show_bug.cgi?id=81661. Should it be done at wherever focus is after keypress event is dispatched? Or whatever keypress event's target was? DOM level 3 events doesn't seem to specify this behavior: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress According to a fellow WebKit contributor, WebKit and Internet Explorer use the current focused element whereas Firefox uses the event target. Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Where should UA insert text when the focus is changed in a keypress event handler?
On 3/20/12 2:58 PM, Ojan Vafai wrote: With my web developer hat on, I would expect the WebKit/IE behavior. Keypress is fired before the DOM is modified (I tested in Gecko and WebKit on an input element). As such, I'd expect focus changed during a keypress event to change where the text is inserted. Notably, Gecko does the WebKit/IE behavior if you use keydown instead of keypress. I don't see any reason keypress should be different from keydown. It's different because if you want to express default actions in terms of, say, system event group event handlers, the default action corresponds to an event handler for the keypress event... and the keypress event fired on the input the focus was shifted from. This is also why it differs from keydown; shifting focus on keydown changes the target of the keypress. -Boris
