[Webkit-unassigned] [Bug 23607] Clicking near an contentEditable div will focus the div, even though it shouldn't!

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 30 14:53:26 PST 2009


https://bugs.webkit.org/show_bug.cgi?id=23607





------- Comment #4 from eric at webkit.org  2009-01-30 14:53 PDT -------
I've attached our first stab.  It's broken.  We're now correctly returning a
good VisualPosition right before the editable div, but canonicalPosition is
turning our returned position into the next div.  I'm not sure what changes we
need to make to canonicalPosition to make this work.  Should our placement be a
"candidate position"?  Should we special case to check if next's editibitility
is not the same as position's?  (That's probably the fix.)

Here's the function for reference:  In our case, we fall out the last return
where it does return next;

Position VisiblePosition::canonicalPosition(const Position& position)
{
    // FIXME (9535):  Canonicalizing to the leftmost candidate means that if
we're at a line wrap, we will 
    // ask renderers to paint downstream carets for other renderers.
    // To fix this, we need to either a) add code to all paintCarets to pass
the responsibility off to
    // the appropriate renderer for VisiblePosition's like these, or b)
canonicalize to the rightmost candidate
    // unless the affinity is upstream.
    Node* node = position.node();
    if (!node)
        return Position();

    node->document()->updateLayoutIgnorePendingStylesheets();

    Position candidate = position.upstream();
    if (candidate.isCandidate())
        return candidate;
    candidate = position.downstream();
    if (candidate.isCandidate())
        return candidate;

    // When neither upstream or downstream gets us to a candidate
(upstream/downstream won't leave 
    // blocks or enter new ones), we search forward and backward until we find
one.
    Position next = canonicalizeCandidate(nextCandidate(position));
    Position prev = canonicalizeCandidate(previousCandidate(position));
    Node* nextNode = next.node();
    Node* prevNode = prev.node();

    // The new position must be in the same editable element. Enforce that
first.
    // Unless the descent is from a non-editable html element to an editable
body.
    if (node->hasTagName(htmlTag) && !node->isContentEditable())
        return next.isNotNull() ? next : prev;

    Node* editingRoot = editableRootForPosition(position);

    // If the html element is editable, descending into its body will look like
a descent 
    // from non-editable to editable content since rootEditableElement() always
stops at the body.
    if (editingRoot && editingRoot->hasTagName(htmlTag) ||
position.node()->isDocumentNode())
        return next.isNotNull() ? next : prev;

    bool prevIsInSameEditableElement = prevNode &&
editableRootForPosition(prev) == editingRoot;
    bool nextIsInSameEditableElement = nextNode &&
editableRootForPosition(next) == editingRoot;
    if (prevIsInSameEditableElement && !nextIsInSameEditableElement)
        return prev;

    if (nextIsInSameEditableElement && !prevIsInSameEditableElement)
        return next;

    if (!nextIsInSameEditableElement && !prevIsInSameEditableElement)
        return Position();

    // The new position should be in the same block flow element. Favor that.
    Node *originalBlock = node->enclosingBlockFlowElement();
    bool nextIsOutsideOriginalBlock = !nextNode->isDescendantOf(originalBlock)
&& nextNode != originalBlock;
    bool prevIsOutsideOriginalBlock = !prevNode->isDescendantOf(originalBlock)
&& prevNode != originalBlock;
    if (nextIsOutsideOriginalBlock && !prevIsOutsideOriginalBlock)
        return prev;

    return next;
}


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list