https://bugs.webkit.org/show_bug.cgi?id=38548
--- Comment #22 from Erik Arvidsson <arv at chromium.org> 2010-05-07 11:01:27 PST ---
(In reply to comment #21)
> (From update of attachment 55333 [details])
> > - if (Node* mousePressNode = newFocusedFrame->eventHandler()->mousePressNode())
> > - if (mousePressNode->renderer() && !mousePressNode->canStartSelection())
> > - if (Node* root = s->rootEditableElement())
> > - if (Node* shadowAncestorNode = root->shadowAncestorNode())
> > + if (Node* mousePressNode = newFocusedFrame->eventHandler()->mousePressNode()) {
> > + if (mousePressNode->renderer() && !mousePressNode->canStartSelection()) {
> > + // In case selection was in an input or textarea we need to clear the selection. See bug 38696.
> > + if (Node* root = s->rootEditableElement()) {
> > + if (Node* shadowAncestorNode = root->shadowAncestorNode()) {
> > // Don't do this for textareas and text fields, when they lose focus their selections should be cleared
> > // and then restored when they regain focus, to match other browsers.
> > if (!shadowAncestorNode->hasTagName(inputTag) && !shadowAncestorNode->hasTagName(textareaTag))
> > return;
> > + }
> > + } else {
> > + return;
> > + }
> > + }
> > + }
> >
> > s->clear();
> > }
>
> I have a few questions about this patch. First, the comment that you added is
> "In case selection was in an input or textarea we need to clear the selection.
> See bug 38696." But isn't the opposite true? Isn't it that we do NOT want to
> clear the selection in the case of an input or textarea?
We currently clear the selection of textareas and inputs because if there is an
existing selection in editable element in the document then any keyboard event
gets routed back to the editable element (even if it does not have focus). This
is what bug 38696 is about.
> Also, are you certain that adding an else to the (Node* root =
> s->rootEditableElement()) case is correct? Can you be certain that this will
> only apply to inputs and textareas like your comment implies?
Bug 38696 covers this. contentEditable elements go all the way into the
innermost if check but they don't match the condition so we exit the function
there. That is why they steal the keyboard input and focus.
However, I did not want to make that change here since I'd rather do that in
another patch since I'd like to focus on one issue at a time.
Part of fixing 38696 would be to make that last if statement simply:
if (Node* mousePressNode = newFocusedFrame->eventHandler()->mousePressNode()) {
if (mousePressNode->renderer() && !mousePressNode->canStartSelection()) {
return;
}
}
HTH
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.