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

[Germain Garand]

Le Lundi 19 Janvier 2004 13:21, Leo Savernik a écrit :

> Time to explain how this code is supposed to work:

thanks, very interesting :-)

> > 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.
>
> The problem with this approach is that the contenteditable element
> semantically *has* the focus, and therefore all actions that apply to
> focusable elements (like tabbing order) should apply to it as well.
>

Ok.

> > 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?
>
> I don't know how many implications DocumentImpl::setFocusNode is supposed
> to make. I have always assumed that setFocusNode unconditionally sets the
> focus to the very element that was passed to it, regardless of whether it
> can take the focus (isSelectable()), or not.
>

mmh, no, there is already about 20 lines of logic in it. Some checkings, some 
event dispatching. 

Germain