[patch] broken keyboard handling in forms (#66296)(grave)

[Germain Garand]

Le Dimanche 18 Janvier 2004 22:55, Leo Savernik a écrit :
> Am Sonntag, 18. Januar 2004 19:07 schrieb Germain Garand:
> > Le Dimanche 18 Janvier 2004 12:43, Leo Savernik a écrit :
> Fix attached which does not break contenteditable and also fixes the issues
> mentioned above.
>

it certainly does work here. 
What about a warning if current focusNode != the node you receive before 
looking for "user-input" node?
I'm wary of more corner cases :)

> > It would be less likely that several unrelated places compete for
> > focusNode ownership, as is the case now.
>
> If you have an idea on how to realize this, I'm interested.
>

mmh, I don't understand exactly your requirements (why the contenteditable 
nodes need keyboard events when !part->editable() and !part->caretMode()? )
so it's hard to tell...
But if the focusNode is not necessarily equal to [the content editable node], 
then you could have your own editableNode member and forward your keyboard 
events to that, rather than hijacking the focusNode.
Otherwise, it they are necessarily equal, and they are redundant, then why not 
move your [try to find first ancestor whose "user-input" is "enabled"] logic 
straight in setFocusNode? You are doing that afterward anyway, so why not 
doing it in the first place?

Germain