Bug 10884 – WebView keyboard navigation does not allow positioning cursor / collapsed selectedDOMRange within empty elements

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: HTML Editing

[Robert Burns]

WebView keyboard naviagaion does not allow positioning cursor / collapsed selectedDOMRange within empty elements. Even if the element has an empty text node within it, the arrow keys move the cursor right past the element.  Along with bug 10883, this means that inserting/appending/replacing a new element will not allow entry of subsequent text into the element.

[Robert Burns]

I should add in gernarl keyboard navigation around inserted elements (including forward and back delete) does not behave consistently with other text systems' UI. For example, back delete can often delete an extra space away or there's now ay to navigate right up to the right side of an element.

[Robert Burns]

(In reply to comment #1)
In reply to my own comment and after further testing the general keyboard navigation (when the document does not contain generated content:; see bug http://bugzilla.opendarwin.org/show_bug.cgi?id=10123) is probably working as intended. In other words its working consistently with other text systems such as the cocoa text system. However, I think when editing HTML/XML content there are some important differences that WebKit should take into consideration. When setting the cursor next to an element, the user requires the ability to place it either inside or outside the element depending on whether the about to be inserted text is part of the element or not. For example (pipe character representes cursor, aka insertion-point aka  collapsed selectedDOMRange)

with this text fragment with a q element the curor could be either "inside|" or "oustide"| the q element.

This example applies to all inline elements though its most visible with the <q> element. In my view the pressing of the left arrow key when the cursor is to the left of the word "outside" should move the cursor inside the inline element. For a <strong> element this means the cursor would not visibly move whiloe for the <q> element the cursor would move to the left of the css generated content. So for most elements the user would simply experience an extra left-arrow pressing when entering or exiting inline elements.

[Robert Burns]

(In reply to comment #2)
> (In reply to comment #1)

Sorry this was meant for a comment on another bug related to this one. This bug is a problem. The abovve comment was meant to clarfity the other keyboard navigation problems. So again, the current WebKit does not allow positioning of the cursor within an empty element either through keyboard navigation or through [aWebView setSelectedDOMRange:aRangInsdieAnEmptyElement] method.

[Alexey Proskuryakov]

Can this be reproduced in Safari? We'll need steps to reproduce and/or a test application to go forward with this issue.

[Ryosuke Niwa]

As far as I understand it, this is a duplicate of the bug 15256.

*** This bug has been marked as a duplicate of bug 15256 ***