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

[Leo Savernik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 19. Januar 2004 11:45 schrieb 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 :)

Time to explain how this code is supposed to work:
With contenteditable, you can have distinct elements which (and whose 
children) are user-input: enabled (i. e. editable) on a page which is 
non-editable. For instance:

<div contenteditable>bla bla</div>
<div>Not editable</div>
<div contenteditable>blu blu</div>

To being able to direct the keyboard input to one of those divs, it must have 
the keyboard focus. If "bla bla" has the focus, and the user clicks into "blu 
blu", the focus must leave "bla bla", and be put onto "blu blu".

Therefore, the current focus node is allowed to be different from the one 
going to be set.

>
> > > 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...

Iff part->isEditable() or part->isCaretMode(), no focus handling takes place 
intentionally, because the whole page is already editable/navigable as soon 
as the document receives the focus. In other words, there's no need for 
contenteditable elements to receive a distinct keyboard focus, as they are 
reachable by the document focus nonetheless.

> 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.

> 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.
>
> Germain

mfg
	Leo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAC9nFj5jssenUYTsRAspfAJ0cMOq/xILhOPONf1l3DB6m7BVUvQCfSwin
OBp8GpNG9C0PDVAqwXgXm0w=
=/KAR
-----END PGP SIGNATURE-----