Bug 10884 - WebView keyboard navigation does not allow positioning cursor / collapsed selectedDOMRange within empty elements
Summary: WebView keyboard navigation does not allow positioning cursor / collapsed sel...
Status: RESOLVED DUPLICATE of bug 15256
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 419.x
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-16 02:23 PDT by Robert Burns
Modified: 2012-05-01 21:24 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Burns 2006-09-16 02:23:57 PDT
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.
Comment 1 Robert Burns 2006-09-16 02:28:39 PDT
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.
Comment 2 Robert Burns 2006-09-19 18:53:11 PDT
(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.
Comment 3 Robert Burns 2006-09-21 21:00:47 PDT
(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.
Comment 4 Alexey Proskuryakov 2007-07-02 05:31:40 PDT
Can this be reproduced in Safari? We'll need steps to reproduce and/or a test application to go forward with this issue.
Comment 5 Ryosuke Niwa 2012-05-01 21:24:41 PDT
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 ***