[Webkit-unassigned] [Bug 10123] when CSS pseudo selectors are applied (:before and :after) the *-of-line keyboard navigation does not work

[bugzilla-daemon at webkit.org]

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


Robert Burns <robburns1 at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10651|0                           |1
        is obsolete|                            |




--- Comment #4 from Robert Burns <robburns1 at mac.com>  2010-01-08 17:08:47 PST ---
Created an attachment (id=46179)
 --> (https://bugs.webkit.org/attachment.cgi?id=46179)
A better example that works in browser (no blot.app required)

My apologies for all of that superfluous metadata. I included that
inadvertantly.

The behavior appears different in the latest Safari WebKit. In general the
existence of generated content still hinders keybaord navigation. The up/down
navigation works better, but is still not right. A down-arrow key event should
always move to the next line whereas depending on where the generated content
is, it could move to later in the same line.

Sometimes the keyboard navigation fails entirely to cross the element boundary
(especially with left and right arrow keydowns). In that case the user can
repeatedly depress the left arrow and the cursor remains in the same place.

This bug does not really affect textarea and input elements but is instead
related to content editable and related elements (whereas the textarea and
input are strictly text/plain).

Perhaps this bug is fixed and a new bug needs to be opened for the remaining
keyboard navigation problems. In terms of start-of-line and end-of-line the
major problem appears to be fixed. I think the behavior is still wrong in terms
of the left and right arrows should not allow the curor to end up on the
previous line or next line respectively (for ltr text). Instead in the event of
a start-of-line action, the curor should end up on the same line and after any
line-wrapping generated content. In the case of moving the selection to the
start-of-line the portion of the generated content itself should be selected on
the same line. Though I imagine this would require a change in the design since
there would be a selectedDOMRange that diverges from the NSRange selection in
the view class.

Perhaps an umbrella bug for keyboard navigation/selection with sub bugs for
each specific problem. Other related keyboard navigation and selection issues
(other than this one regarding generated content):

1) paragraph (shift-option-arrow) selection does not work as it does in
NSTextView, but instead does something like selecting to the same place in the
next paragraph (rather than to the beginning or end of the current paragraph).
2) the issue you raise where extending selections using the keyboard should
work even without contentEditable=true. It works for shift-option-arrow but not
for shif-command-arrow.

There may be others, but those are the big ones I can think of now.

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