focus change inside keypress event handler

[Michael A. Puls II]

(CCing DOM list just in case anyone there has any comments)

With:

<p><input onkeypress="this.nextSibling.focus()"><input></p>

, if you type a character in the first field, should the character be  
entered in the second field or the first?

In Firefox and Safari, it's the first field. In IE and Opera, it's the  
second.

I'm pretty sure Opera's model is just old, willful compat with IE.

However, with  
<https://chaseonline.chase.com/chaseonline/signup/sso_signup_filter.jsp?LOB=RBGLogon>,  
it has an IE code path and a FF code path. In Opera's case, it gets the FF  
code path. That's good, but Opera's not compatible with FF in this case.

Right now, Opera has a workaround in its browser.js to solve this.  
However, I believe Opera might eventually change to be like FF and Safari  
(in which case the workaround would be removed), but not totally sure.

I do think FF and Safari's way makes more sense and I think most will  
agree.  Could you make sure the spec is clear on this.

(I think I mentioned this before but cannot find the message or text in  
HTML5 that says what to do for sure.)

--
Michael

[Thomas Broyer-2]

On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
<shadow2531@...> wrote:

> (CCing DOM list just in case anyone there has any comments)
>
> With:
>
> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>
> , if you type a character in the first field, should the character be
> entered in the second field or the first?
>
> In Firefox and Safari, it's the first field. In IE and Opera, it's the
> second.

[...]
> I do think FF and Safari's way makes more sense and I think most will agree.

If we consider keypress to be the same as DOM-3 Events' textinput,
then it makes way more sense for the char to be added to the first
field (i.e. the Gecko/WebKit way).

My .2c

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Jacob Rossi-2]

On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
<shadow2531@...> wrote:
> (CCing DOM list just in case anyone there has any comments)
>
> With:
>
> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>
> , if you type a character in the first field, should the character be
> entered in the second field or the first?
>
> In Firefox and Safari, it's the first field. In IE and Opera, it's the
> second.
[...]
> I do think FF and Safari's way makes more sense and I think most will agree.

 

The keypress event is similar to textInput.  Their intent is to indicate when character data has been entered. textInput is more powerful and captures character input from a number of input sources (keyboard, IME, voice, etc). In both cases, I would consider the default action to be the insertion of the characters into the DOM. For *most* events, the default action isn't performed until after event dispatch. Accordingly, I would expect that calling focus() during the dispatch of the keypress (or textInput) event would result in moving the cursor prior to the character data being inserted (because events are synchronous). Thus I think it makes most sense for the character to appear in the second input box.

 

Another reason why this should be the case is what happens when you cancel the default action (call preventDefault() ). Canceling a textInput or keypress event should prevent the character from being inserted. So that's further evidence that the character insertion should happen after dispatch of the event.

--Jacob

[Jacob Rossi-2]

I should add that if you want the the character to appear in the first input field, then use keyup to redirect the focus (because it occurs after keypress and the character insertion). The only caveat here is that it assumes input from the keyboard (ex: a textinput event generated from handwriting recognition would not be followed by a keyup event). But your original question used keypress, so I'll assume it's safe to make this assumption.

--Jacob

On Wed, Oct 28, 2009 at 10:57 AM, Jacob Rossi <rossi@...> wrote:

On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
<shadow2531@...> wrote:
> (CCing DOM list just in case anyone there has any comments)
>
> With:
>
> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>
> , if you type a character in the first field, should the character be
> entered in the second field or the first?
>
> In Firefox and Safari, it's the first field. In IE and Opera, it's the
> second.
[...]
> I do think FF and Safari's way makes more sense and I think most will agree.

 

The keypress event is similar to textInput.  Their intent is to indicate when character data has been entered. textInput is more powerful and captures character input from a number of input sources (keyboard, IME, voice, etc). In both cases, I would consider the default action to be the insertion of the characters into the DOM. For *most* events, the default action isn't performed until after event dispatch. Accordingly, I would expect that calling focus() during the dispatch of the keypress (or textInput) event would result in moving the cursor prior to the character data being inserted (because events are synchronous). Thus I think it makes most sense for the character to appear in the second input box.

 

Another reason why this should be the case is what happens when you cancel the default action (call preventDefault() ). Canceling a textInput or keypress event should prevent the character from being inserted. So that's further evidence that the character insertion should happen after dispatch of the event.

--Jacob

[Michael A. Puls II]

On Wed, 28 Oct 2009 10:57:43 -0400, Jacob Rossi <rossi@...> wrote:

> On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
> <shadow2531@...<shadow2531@...?Subject=Re%3A%20%5Bwhatwg%5D%20focus%20change%20inside%20keypress%20event%20handler&In-Reply-To=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E&References=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E>>
> wrote:
>> (CCing DOM list just in case anyone there has any comments)
>>
>> With:
>>
>> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>>
>> , if you type a character in the first field, should the character be
>> entered in the second field or the first?
>>
>> In Firefox and Safari, it's the first field. In IE and Opera, it's the
>> second.
> [...]
>> I do think FF and Safari's way makes more sense and I think most will
> agree.
>
> The keypress event is similar to textInput.  Their intent is to indicate
> when character data has been entered. textInput is more powerful and
> captures character input from a number of input sources (keyboard, IME,
> voice, etc). In both cases, I would consider the default action to be the
> insertion of the characters into the DOM. For *most* events, the default
> action isn't performed until after event dispatch. Accordingly, I would
> expect that calling focus() during the dispatch of the keypress (or
> textInput) event would result in moving the cursor prior to the character
> data being inserted (because events are synchronous). Thus I think it  
> makes
> most sense for the character to appear in the second input box.
>
> Another reason why this should be the case is what happens when you  
> cancel
> the default action (call preventDefault() ). Canceling a textInput or
> keypress event should prevent the character from being inserted. So  
> that's
> further evidence that the character insertion should happen after  
> dispatch
> of the event.

Thanks. That makes sense technically.

Safari and Firefox will allow focus() inside the handler to decide where  
the character gets inserted, but only with "keydown". With "keypress" (and  
textInput in webkit) in Firefox and Safari, it appears that the char was  
already inserted right after keydown, so a focus() change is already too  
late. Despite that though, preventDefault() still works in Firefox and  
Safari inside a "keypress" handler to prevent the char from being  
inserted. So, I'm not exactly sure what's they're doing behind the scenes.

Note that Opera for example doesn't allow preventDefault() to have any  
effect in the keydown handler. It only works in the "keypress" handler  
more like you expect.

For clarification, if I press 'd' in the first input of:

<p><input><input></p>
<script>
window.onload = function() {
var inp = document.getElementsByTagName("input")[0];
function test(e) {
     alert(e.type);
}
inp.addEventListener("textInput", test, false);
inp.addEventListener("keydown", test, false);
inp.addEventListener("keypress", test, false);
inp.addEventListener("keyup", test, false);
};
</script>

1. What order do those fire in?

2. What ones can you use preventDefault() in to stop the character from  
being inserted?

3. For each one that you can use preventDefault() in to stop the insertion  
of the 'd', if you use preventDefault(), which of the others will not fire?

4. When is the 'd' actually suppposed to be inserted (what the spec says,  
not necessarily what browsers do)? (This will help determine what handlers  
you can use focus() in to change what field the typed char gets inserted  
in)

Also:

5. What are the list of keys that trigger keydown? (or do not if that's  
easier)

6. What are the list of keys that trigger keypress? (or do not if that's  
easier)

7. What are the list of keys that trigger keyup? (or do not if that's  
easier)

8. For HTML5 and the 'input' event, if I add another lineto the above,  
inp.addEventListener('input', test, false), when does 'input' fire? Before  
the others? After the others? Does #3 apply here?

Basically, if anyone can describe in words all the steps that should  
happen with the example code above, that'd be great. (If it's even defined  
anywhere)

Thanks

In short though, browsers don't agree on this stuff and it's difficult to  
decide what the right thing to do is in regards to "how it's supposed to  
work". I could even throw other events that detect modification of the  
fields value to complicate things even more.

--
Michael

[Boris Zbarsky]

On 10/29/09 9:20 AM, Michael A. Puls II wrote:
> Despite that though, preventDefault() still works in
> Firefox and Safari inside a "keypress" handler to prevent the char from
> being inserted. So, I'm not exactly sure what's they're doing behind the
> scenes.

Last I checked in Gecko, things looked somewhat like this:

Editors (those editable things inside text inputs) set up some default
actions (effectively event listeners in the system event group).  The
default keypress event action is to enter the character.

When you press a button on your keyboard, the focus is used for one
thing and one thing only: to decide where to dispatch the key events.
So the keypress event is dispatched to the thing that has focus.  If one
of the event handlers for keypress changes what has the focus, that
doesn't change where the default action of the keypress event takes
place (since the event target chain is built completely before any of
the event handling takes place).

Make sense?

> Note that Opera for example doesn't allow preventDefault() to have any
> effect in the keydown handler. It only works in the "keypress" handler
> more like you expect.

You might be interested in
https://bugzilla.mozilla.org/show_bug.cgi?id=167145

> 1. What order do those fire in?
>
> 2. What ones can you use preventDefault() in to stop the character from
> being inserted?
>
> 3. For each one that you can use preventDefault() in to stop the
> insertion of the 'd', if you use preventDefault(), which of the others
> will not fire?

These are all excellent questions that the spec should answer.

> 4. When is the 'd' actually suppposed to be inserted (what the spec
> says, not necessarily what browsers do)? (This will help determine what
> handlers you can use focus() in to change what field the typed char gets
> inserted in)

This is two separate questions:

1)  When is the 'd' actually inserted?
2)  When is the element the 'd' will be inserted in determined?

In Gecko, the answers are effectively:

1)  During the default action phase of the keypress event,
     assuming that it has not had preventDefault() called via
     various mechanisms (e.g. preventDefault() on keydown will
     trigger preventDefault on all resulting keypresses in Gecko).
2)  Immediately before the keypress event is fired.

(two sides of the same coin, really, since this is just how default
actions work in DOM event land).

> In short though, browsers don't agree on this stuff and it's difficult
> to decide what the right thing to do is in regards to "how it's supposed
> to work". I could even throw other events that detect modification of
> the fields value to complicate things even more.

Yep.  And you could use script to set .value at various points in there,
leading to fun questions about how onchange should work, too.  It's a
mess.  ;)

-Boris

[Scott González]

On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II <shadow2531@...> wrote:

Safari and Firefox will allow focus() inside the handler to decide where the character gets inserted, but only with "keydown". With "keypress" (and textInput in webkit) in Firefox and Safari, it appears that the char was already inserted right after keydown, so a focus() change is already too late. Despite that though, preventDefault() still works in Firefox and Safari inside a "keypress" handler to prevent the char from being inserted. So, I'm not exactly sure what's they're doing behind the scenes.

DOM Level 3 Events says "The default action of the keypress event depends upon the key and the context: if the key is associated with a character, and if there currently focused element in the document can receive text (such as a form input or an editable text block), the default action is to dispatch a textInput event with the character as the value of the TextEvent.data attribute"

The default action of a keypress is not to insert a character in the element that has focus, but to insert a character on the element that represents the context of the keypress. In the given example, the keypress's context is the first field, not the second. I agree though that the documentation could be clearer about this as it's not explicitly stated.

[Michael A. Puls II]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Thu, 29 Oct 2009 10:14:42 -0400, Boris Zbarsky <bzbarsky@...> wrote:

> On 10/29/09 9:20 AM, Michael A. Puls II wrote:
>> Despite that though, preventDefault() still works in
>> Firefox and Safari inside a "keypress" handler to prevent the char from
>> being inserted. So, I'm not exactly sure what's they're doing behind the
>> scenes.
>
> Last I checked in Gecko, things looked somewhat like this:
>
> Editors (those editable things inside text inputs) set up some default  
> actions (effectively event listeners in the system event group).  The  
> default keypress event action is to enter the character.
>
> When you press a button on your keyboard, the focus is used for one  
> thing and one thing only: to decide where to dispatch the key events. So  
> the keypress event is dispatched to the thing that has focus.  If one of  
> the event handlers for keypress changes what has the focus, that doesn't  
> change where the default action of the keypress event takes place (since  
> the event target chain is built completely before any of the event  
> handling takes place).
>
> Make sense?

I think so. The event target isn't changed by focus().

But, in Firefox, Safari and Opera, it's possible to change what element  
the text is inserted into by changing the focus in 'keydown'.

>> Note that Opera for example doesn't allow preventDefault() to have any
>> effect in the keydown handler. It only works in the "keypress" handler
>> more like you expect.
>
> You might be interested in  
> https://bugzilla.mozilla.org/show_bug.cgi?id=167145

Thanks. Read all of it. That helps with the history of it and the thoughts  
at the time.

>> 1. What order do those fire in?
>>
>> 2. What ones can you use preventDefault() in to stop the character from
>> being inserted?
>>
>> 3. For each one that you can use preventDefault() in to stop the
>> insertion of the 'd', if you use preventDefault(), which of the others
>> will not fire?
>
> These are all excellent questions that the spec should answer.

Yes indeed.

>> 4. When is the 'd' actually suppposed to be inserted (what the spec
>> says, not necessarily what browsers do)? (This will help determine what
>> handlers you can use focus() in to change what field the typed char gets
>> inserted in)
>
> This is two separate questions:
>
> 1)  When is the 'd' actually inserted?
> 2)  When is the element the 'd' will be inserted in determined?
>
> In Gecko, the answers are effectively:
>
> 1)  During the default action phase of the keypress event,
>      assuming that it has not had preventDefault() called via
>      various mechanisms (e.g. preventDefault() on keydown will
>      trigger preventDefault on all resulting keypresses in Gecko).
> 2)  Immediately before the keypress event is fired.
>
> (two sides of the same coin, really, since this is just how default  
> actions work in DOM event land).

O.K., thanks.

>> In short though, browsers don't agree on this stuff and it's difficult
>> to decide what the right thing to do is in regards to "how it's supposed
>> to work". I could even throw other events that detect modification of
>> the fields value to complicate things even more.
>
> Yep.  And you could use script to set .value at various points in there,  
> leading to fun questions about how onchange should work, too.  It's a  
> mess.  ;)

:)

Does the following description make sense (ignoring textInput for now) or  
sound good?

'keydown' fires first.

If a handler for 'keydown' calls preventDefault() (explicitly or  
implicitly via returning false), do not fire 'keypress' after the  
'keydown' handler returns.

If a handler for 'keydown' does not call preventDefault(), and the key  
pressed represents text, after the 'keydown' handler returns, fire  
'keypress' with the insertion context element (Thanks Scott for the  
'context' hint) being the element that's currently focused after the  
'keydown' handler returns and right before 'keypress' is fired. If the key  
pressed does not represent text, do not fire 'keypress'.

If 'keypress' was fired, and the handler for it calls preventDefault()  
(explicitly or implicitly via return false), after the handler returns, do  
not insert the text.

If 'keypress' was fired and the handler for it does not call  
preventDefault(), after the handler returns, insert the text in the  
insertion context element.

If the key is being held down, 'keydown' or both 'keydown' first and then  
'keypress' second will fire repeatedly according to the rules above.

Once the key is finally released and 'keydown' stops firing, always fire  
'keyup' no matter what.

Note that 'keyup' may fire before 'keypress' if you release the key before  
an alert() inside the 'keydown' handler shows and blocks.

In short, 'keydown' and 'keyup' *always* fire when pressing and releasing  
a key. Whether 'keypress' is fired and something is inserted into the  
field (and which field) and whether keypress fires before keyup, depends  
on the rules above.

(Note that the above description describes how things seem from testing on  
the user/author side, not from the implementation side.)

In testing, that seems to be what Safari Win32 does and it's pretty  
consistent about it. In fact, I chose Safari as a basis for the  
description above because it's consistent and it's easier to see what's  
happening.

It's already been said how Opera is different as far as focus changes in  
'keypress' changing the insertion context element and preventDefault() not  
working in 'keydown' go. But, Opera also does something else differently.  
When holding down a key, it just repeatedly fires 'keypress', instead of  
just 'keydown' or both 'keydown and 'keypress' like Firefox and Safari.

As for Firefox, it's different too in that preventDefault() doesn't stop  
any events from firing. It just stops text insertion in some cases.

Attached is one doc I was testing with. Uncomment one or both of the  
preventDefaults() to play around.

I realize there's more to things than that, but that's a starting  
*example* of the detail I think the spec should cover.

Ultimately though, the spec should define all this stuff clearly in a way  
that all browsers can implement. Browsers just shouldn't be different in  
this area. It's too creepy. :)

Thanks

--
Michael

Type text or non-text key to see what happens

[Boris Zbarsky]

On 10/29/09 5:24 PM, Michael A. Puls II wrote:
> I think so. The event target isn't changed by focus().
>
> But, in Firefox, Safari and Opera, it's possible to change what element
> the text is inserted into by changing the focus in 'keydown'.

Right; that happens because the keydown and keypress events need not
fire on the same element and because the text entry is the keypress
default action.  In Gecko, that is.  I can't speak to Safari and Opera.

> 'keydown' fires first.
>
> If a handler for 'keydown' calls preventDefault() (explicitly or
> implicitly via returning false), do not fire 'keypress' after the
> 'keydown' handler returns.

No.  That breaks sites, at least in our experience (as described in
https://bugzilla.mozilla.org/show_bug.cgi?id=167145).

> If the key is being held down, 'keydown' or both 'keydown' first and
> then 'keypress' second will fire repeatedly according to the rules above.

This seems wrong to me.  If a key is held down, I would expect a single
keydown followed by multiple keypresses.

> Note that 'keyup' may fire before 'keypress' if you release the key
> before an alert() inside the 'keydown' handler shows and blocks.

This seems unfortunate, but ok.

 > When holding down a key, it just repeatedly fires
> 'keypress', instead of just 'keydown' or both 'keydown and 'keypress'
> like Firefox and Safari.

That behavior makes a lot of sense to me, actually.

> As for Firefox, it's different too in that preventDefault() doesn't stop
> any events from firing. It just stops text insertion in some cases.

Yes. We found that to be necessary for web compat.

> Ultimately though, the spec should define all this stuff clearly in a
> way that all browsers can implement.

Yes, though there might be some interesting differences here modulo what
events the browser's host environment supports...

-Boris

[Michael A. Puls II]

On Thu, 29 Oct 2009 20:51:48 -0400, Boris Zbarsky <bzbarsky@...> wrote:

> On 10/29/09 5:24 PM, Michael A. Puls II wrote:
>> I think so. The event target isn't changed by focus().
>>
>> But, in Firefox, Safari and Opera, it's possible to change what element
>> the text is inserted into by changing the focus in 'keydown'.
>
> Right; that happens because the keydown and keypress events need not  
> fire on the same element and because the text entry is the keypress  
> default action.  In Gecko, that is.  I can't speak to Safari and Opera.

So, just to be sure, you're happy with that behavior?

>> 'keydown' fires first.
>>
>> If a handler for 'keydown' calls preventDefault() (explicitly or
>> implicitly via returning false), do not fire 'keypress' after the
>> 'keydown' handler returns.
>
> No.  That breaks sites, at least in our experience (as described in  
> https://bugzilla.mozilla.org/show_bug.cgi?id=167145).

O.K., will assume that 'keypress' always needs to fire then.

>> If the key is being held down, 'keydown' or both 'keydown' first and
>> then 'keypress' second will fire repeatedly according to the rules  
>> above.
>
> This seems wrong to me.  If a key is held down, I would expect a single  
> keydown followed by multiple keypresses.

O.K. FF doesn't do that though. If you hold down a key, it'll do:
keydown
keypress

over and over.

At quick thought, are you O.K. with FF's current behavior being a bug?

>> Note that 'keyup' may fire before 'keypress' if you release the key
>> before an alert() inside the 'keydown' handler shows and blocks.
>
> This seems unfortunate, but ok.

Is there a good way to solve that though? Or is that something that should  
just be left as YMMV?

>  > When holding down a key, it just repeatedly fires
>> 'keypress', instead of just 'keydown' or both 'keydown and 'keypress'
>> like Firefox and Safari.
>
> That behavior makes a lot of sense to me, actually.

O.K., cool.

>> As for Firefox, it's different too in that preventDefault() doesn't stop
>> any events from firing. It just stops text insertion in some cases.
>
> Yes. We found that to be necessary for web compat.

O.K., cool.

>> Ultimately though, the spec should define all this stuff clearly in a
>> way that all browsers can implement.
>
> Yes, though there might be some interesting differences here modulo what  
> events the browser's host environment supports...

Understood.

I'll put together a new description with the changes to see if sounds good.

Thanks very much.

--
Michael

[Maciej Stachowiak]

On Oct 29, 2009, at 5:51 PM, Boris Zbarsky wrote:

> On 10/29/09 5:24 PM, Michael A. Puls II wrote:
>> I think so. The event target isn't changed by focus().
>>
>> But, in Firefox, Safari and Opera, it's possible to change what  
>> element
>> the text is inserted into by changing the focus in 'keydown'.
>
> Right; that happens because the keydown and keypress events need not  
> fire on the same element and because the text entry is the keypress  
> default action.  In Gecko, that is.  I can't speak to Safari and  
> Opera.

WebKit also makes typing take effect as the default action for  
"keypress", at least for normal typing. It's more complicated when  
international text input methods are in play.

Regards,
Maciej

[Doug Schepers-3]

Hi, Folks-

Scott González wrote (on 10/29/09 11:03 AM):

> On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II
> <shadow2531@... <mailto:shadow2531@...>> wrote:
>
>     Safari and Firefox will allow focus() inside the handler to decide
>     where the character gets inserted, but only with "keydown". With
>     "keypress" (and textInput in webkit) in Firefox and Safari, it
>     appears that the char was already inserted right after keydown, so a
>     focus() change is already too late. Despite that though,
>     preventDefault() still works in Firefox and Safari inside a
>     "keypress" handler to prevent the char from being inserted. So, I'm
>     not exactly sure what's they're doing behind the scenes.
>
>
> DOM Level 3 Events says "The default action of the keypress event
> depends upon the key and the context: if the key is associated with a
> character, and if there currently focused element in the document can
> receive text (such as a form input or an editable text block), the
> default action is to dispatch a textInput event with the character as
> the value of the TextEvent.data attribute"
>
> The default action of a keypress is not to insert a character in the
> element that has focus, but to insert a character on the element that
> represents the context of the keypress. In the given example, the
> keypress's context is the first field, not the second.

Correct.


> I agree though
> that the documentation could be clearer about this as it's not
> explicitly stated.

Yes, more clarification for focus and for key events is in the works for
DOM3 Events... this thread has a bunch of great data and questions,
thank you.  I expect that HTML5 will probably also say something about this.

Regards-
-Doug

[Boris Zbarsky]

On 10/29/09 10:16 PM, Maciej Stachowiak wrote:
> WebKit also makes typing take effect as the default action for
> "keypress", at least for normal typing. It's more complicated when
> international text input methods are in play.

Yeah, when IME is involved I have no idea what events are fired in Gecko
and when.

-Boris

[Boris Zbarsky]

On 10/29/09 9:58 PM, Michael A. Puls II wrote:
>>> But, in Firefox, Safari and Opera, it's possible to change what element
>>> the text is inserted into by changing the focus in 'keydown'.
>>
>> Right; that happens because the keydown and keypress events need not
>> fire on the same element and because the text entry is the keypress
>> default action. In Gecko, that is. I can't speak to Safari and Opera.
>
> So, just to be sure, you're happy with that behavior?

Which?  It being possible to change focus in keydown and thus change
where the text will go?

I'm pretty agnostic on whether that should be possible or not.
Whichever way makes the event model simpler, I think.

>> This seems wrong to me. If a key is held down, I would expect a single
>> keydown followed by multiple keypresses.
>
> O.K. FF doesn't do that though. If you hold down a key, it'll do:
> keydown
> keypress
>
> over and over.
>
> At quick thought, are you O.K. with FF's current behavior being a bug?

I don't know.  It's worth looking up why the behavior is as it is (that
is, what web sites depend on).  Multiple keypresses in this situation
are a definite necessity.

>>> Note that 'keyup' may fire before 'keypress' if you release the key
>>> before an alert() inside the 'keydown' handler shows and blocks.
>>
>> This seems unfortunate, but ok.
>
> Is there a good way to solve that though? Or is that something that
> should just be left as YMMV?

Well, you could require an alert to block all key event delivery to the
web page, right?

-Boris

[Olli Pettay]

On 10/30/09 7:26 AM, Boris Zbarsky wrote:
> On 10/29/09 10:16 PM, Maciej Stachowiak wrote:
>> WebKit also makes typing take effect as the default action for
>> "keypress", at least for normal typing. It's more complicated when
>> international text input methods are in play.
>
> Yeah, when IME is involved I have no idea what events are fired in Gecko
> and when.

When IME is involved Gecko dispatches keydown, keypress,
compositionstart, text+, compositionend, keyup.

D3E has compositionstart, compositionupdate (which is a lot better name
than 'text') and compositionend.

In Gecko IME doesn't really make key event handling more complicated,
though the default handling is a bit different with keypress.
(I should re-test default handling with IME.)



-Olli

[Michael A. Puls II]

On Fri, 30 Oct 2009 01:29:00 -0400, Boris Zbarsky <bzbarsky@...> wrote:

> On 10/29/09 9:58 PM, Michael A. Puls II wrote:
>>>> But, in Firefox, Safari and Opera, it's possible to change what  
>>>> element
>>>> the text is inserted into by changing the focus in 'keydown'.
>>>
>>> Right; that happens because the keydown and keypress events need not
>>> fire on the same element and because the text entry is the keypress
>>> default action. In Gecko, that is. I can't speak to Safari and Opera.
>>
>> So, just to be sure, you're happy with that behavior?
>
> Which?  It being possible to change focus in keydown and thus change  
> where the text will go?

Yes.

> I'm pretty agnostic on whether that should be possible or not. Whichever  
> way makes the event model simpler, I think.
>
>>> This seems wrong to me. If a key is held down, I would expect a single
>>> keydown followed by multiple keypresses.
>>
>> O.K. FF doesn't do that though. If you hold down a key, it'll do:
>> keydown
>> keypress
>>
>> over and over.
>>
>> At quick thought, are you O.K. with FF's current behavior being a bug?
>
> I don't know.  It's worth looking up why the behavior is as it is (that  
> is, what web sites depend on).  Multiple keypresses in this situation  
> are a definite necessity.

Thanks. Opera seems to get a way with the multiple keydowns. But, its user  
base isn't as large, so, I'm not sure how much weight that has.

>>>> Note that 'keyup' may fire before 'keypress' if you release the key
>>>> before an alert() inside the 'keydown' handler shows and blocks.
>>>
>>> This seems unfortunate, but ok.
>>
>> Is there a good way to solve that though? Or is that something that
>> should just be left as YMMV?
>
> Well, you could require an alert to block all key event delivery to the  
> web page, right?

Would that be a desirable solution? Is that hard to implement?

--
Michael

[Boris Zbarsky]

On 10/30/09 6:41 PM, Michael A. Puls II wrote:
>>> Is there a good way to solve that though? Or is that something that
>>> should just be left as YMMV?
>>
>> Well, you could require an alert to block all key event delivery to
>> the web page, right?
>
> Would that be a desirable solution? Is that hard to implement?

I don't know, and I don't know.  The answer to the latter question
depends strongly on the precise event model the browser is using, how it
interacts with the OS, what it actually does for alert, etc.

-Boris

[Michael A. Puls II]

On Fri, 30 Oct 2009 18:56:33 -0400, Boris Zbarsky <bzbarsky@...> wrote:

> On 10/30/09 6:41 PM, Michael A. Puls II wrote:
>>>> Is there a good way to solve that though? Or is that something that
>>>> should just be left as YMMV?
>>>
>>> Well, you could require an alert to block all key event delivery to
>>> the web page, right?
>>
>> Would that be a desirable solution? Is that hard to implement?
>
> I don't know, and I don't know.  The answer to the latter question  
> depends strongly on the precise event model the browser is using, how it  
> interacts with the OS, what it actually does for alert, etc.

O.K. Thanks

--
Michael

[Michael A. Puls II]

On Fri, 30 Oct 2009 00:34:14 -0400, Doug Schepers <schepers@...> wrote:

> Hi, Folks-
>
> Scott González wrote (on 10/29/09 11:03 AM):
>> On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II
>> <shadow2531@... <mailto:shadow2531@...>> wrote:
>>
>>     Safari and Firefox will allow focus() inside the handler to decide
>>     where the character gets inserted, but only with "keydown". With
>>     "keypress" (and textInput in webkit) in Firefox and Safari, it
>>     appears that the char was already inserted right after keydown, so a
>>     focus() change is already too late. Despite that though,
>>     preventDefault() still works in Firefox and Safari inside a
>>     "keypress" handler to prevent the char from being inserted. So, I'm
>>     not exactly sure what's they're doing behind the scenes.
>>
>>
>> DOM Level 3 Events says "The default action of the keypress event
>> depends upon the key and the context: if the key is associated with a
>> character, and if there currently focused element in the document can
>> receive text (such as a form input or an editable text block), the
>> default action is to dispatch a textInput event with the character as
>> the value of the TextEvent.data attribute"
>>
>> The default action of a keypress is not to insert a character in the
>> element that has focus, but to insert a character on the element that
>> represents the context of the keypress. In the given example, the
>> keypress's context is the first field, not the second.
>
> Correct.

So, you're saying that changing the focus() to another field inside the  
'keydown' handler (or keypress handler in the case of Opera and IE) MUST  
NOT change the insertion context (the field in this case that the text  
gets inserted into)?

If so, that would seem to contradict what browsers do when the focus  
changes inside  a 'keydown' handler and contradicts Opera and IE for focus  
changes inside a 'keypress' handler.

Not allowing that would break chase.com's SSI entry for example. (It uses  
3 fields and moves to the next field after you've entered 3 numbers, then  
2, then 4.

I've noticed lots of sites that change focus as you're typing to move the  
rest of the text to the next field. I'm not sure how many do the focus  
change inside a handler instead of after/before though.

--
Michael

[Michael A. Puls II]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Fri, 30 Oct 2009 18:56:33 -0400, Boris Zbarsky <bzbarsky@...> wrote:

> On 10/30/09 6:41 PM, Michael A. Puls II wrote:
>>>> Is there a good way to solve that though? Or is that something that
>>>> should just be left as YMMV?
>>>
>>> Well, you could require an alert to block all key event delivery to
>>> the web page, right?
>>
>> Would that be a desirable solution? Is that hard to implement?
>
> I don't know, and I don't know.  The answer to the latter question  
> depends strongly on the precise event model the browser is using, how it  
> interacts with the OS, what it actually does for alert, etc.

Another thing I noticed:

With the attached, 'keyup' doesn't fire if you use an alert() in the  
'keydown' or 'keypress' handler.

Well, actually, it fires sometimes in Firefox and Safari, but it's not  
very consistent. Avoiding alert()s makes things more consistent.

I also noticed that with the attached in Opera, if you press the spacebar  
in the field, the alert that pops up disappears right away because the  
space somehow gets invoked on the OK button on the alert().

--
Michael