Page MenuHomePhabricator

VisualEditor: Ctrl+left/right to jump by word does not work properly
Closed, ResolvedPublic

Description

Pressing ctrl + left or right arrow key is supposed to move the caret one word over. (Or at least, that's the normal result in most text editors, I think...) In VisualEditor if you have, for example: ("|" represents the caret)
...Lorem| ipsum
and the user presses ctrl+right, the result is
...Lorem |ipsum
when it is supposed to result in
...Lorem ipsum|


Version: unspecified
Severity: normal

Details

Reference
bz33064

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:08 AM
bzimport set Reference to bz33064.

More precisely, the caret visits every word twice - at the beginning and at the end:
Lorem| ipsum dolor sit amet
Lorem |ipsum dolor sit amet
Lorem ipsum| dolor sit amet
Lorem ipsum |dolor sit amet
Lorem ipsum dolor| sit amet
Lorem ipsum dolor |sit amet
Lorem ipsum dolor sit| amet
Lorem ipsum dolor sit |amet
Lorem ipsum dolor sit amet|

And i would expect something like:
Lorem| ipsum dolor sit amet
Lorem |ipsum dolor sit amet
Lorem ipsum |dolor sit amet
Lorem ipsum dolor |sit amet
Lorem ipsum dolor sit |amet

Another consideration:

I'm not a Mac person, but AFAIK Ctrl-←/→ on OS X does something like Home/End - jumps to the beginning/end of the line. So for Mac users this should emulate their OS' behavior.

ashish.dubey91 wrote:

This implementation fixes the bug for me.

I made a small tweak in es.SurfaceView.js which gives me the expected result as mentioned above.
Awaits review.

Attached:

sumanah wrote:

Ashish, thank you for the patch. I have added the keywords "patch" and "need-review" to indicate that this bug has a patch that needs to be reviewed. Next time, you can do this yourself when you attach the patch, to save time.

Trevor, maybe you could take a look at this?

  • Bug 33146 has been marked as a duplicate of this bug. ***

This patch works, but is still incomplete because it doesn't handle punctuation properly.

On a Mac, using option+left/right yields the following results:

Forwards:

|This.is.a.test of how.things work. if, there-is punctuation.
This.is.a.test| of how.things work. if, there-is punctuation.
This.is.a.test of| how.things work. if, there-is punctuation.
This.is.a.test of how.things| work. if, there-is punctuation.
This.is.a.test of how.things work|. if, there-is punctuation.
This.is.a.test of how.things work. |if, there-is punctuation.
This.is.a.test of how.things work. if|, there-is punctuation.
This.is.a.test of how.things work. if, there|-is punctuation.
This.is.a.test of how.things work. if, there-is| punctuation.
This.is.a.test of how.things work. if, there-is punctuation|.
This.is.a.test of how.things work. if, there-is punctuation.|

Backwards:

This.is.a.test of how.things work. if, there-is punctuation.|
This.is.a.test of how.things work. if, there-is |punctuation.
This.is.a.test of how.things work. if, there-|is punctuation.
This.is.a.test of how.things work. if, |there-is punctuation.
This.is.a.test of how.things work. |if, there-is punctuation.
This.is.a.test of how.things |work. if, there-is punctuation.
This.is.a.test of |how.things work. if, there-is punctuation.
This.is.a.test |of how.things work. if, there-is punctuation.
|This.is.a.test of how.things work. if, there-is punctuation.

It's important to note that hyphens (-) are treated as whitespace. Thus the following two lines will behave identically forwards and backwards.

a -b c- d-e f
a b c d e f

The logic appears to be something like this:

  • Ignore leading punctuation or whitespace
  • Advance to the end of the next word (series of contiguous non punctuation or whitespace characters)

If the patch is updated to follow that logic, that should work well on Mac, but may still not work correctly on other platforms. This is because, as mentioned, moving the cursor by word may differ on Windows or Linux, and we should probably aim to provide a consistent experience on each platform.

If someone can analyze the behavior of other platforms that would be useful.

Also, please note in the examples above, there are three classes of punctuation which seem to behave differently.

  1. Treated as punctuation and skipped over like whitespace:

a!b a@b a#b a%b a&b a*b a(b a)b a-b a{b a}b a[b a]b a\b a;b a"b a,b a?b a/b

  1. Treated as words of their own:

a$b a^b a+b a=b a|b a<b a>b

  1. Treated as part of the word:

a_b a:b a'b a.b

This might also vary from platform to platform.

Also, if you can put together a patch that does this correctly, perhaps some
documentation on the wiki about the different cursor movement rules for each
platform would be awesome.

This is a great project for someone getting into VE work, and we would really
appreciate some help in these areas where the details are important but we are
mostly busy forging ahead with missing functionality.

Thanks for the patch so far, I look forward to getting this working properly.

From

https://www.mediawiki.org/w/index.php?title=Visual_editor/Feedback&oldid=552919#CTRL.2BLeft_arrow_doesn.27t_work_as_expected

I was trying to use CTRL+Left arrow to move the cursor to the left, but it only moves one character at time (instead of one word at time).
Curiously, it works fine for selection (i.e. CTRL+SHIFT+Left arrow).

The right arrow behaves the same way as the left one.

For the record, here is what I get on Ubuntu 12.04, using gedit 3.4.1 for the examples from comment 7 (I inserted a "|" on each place the cursor stops when going to each direction):

Forwards:

a!ba@Ba#ba%ba&ba*ba(ba)ba-ba{ba}ba[ba]ba\ba;ba"ba,ba?ba/b
a$ba^ba+ba=baba<ba>b
a_ba:ba'ba.b

Backwards:

a!ba@ba#ba%ba&ba*ba(ba)ba-ba{ba}baba]ba\ba;ba"ba,ba?ba/b
a$ba^ba+ba=baba<ba>b
a_ba:ba'ba.b

Here's how it is for me (also some related issues):

  • Ctrl + ← or Ctrl + → only moves the cursor for one character.
  • Ctrl + Shift + ← or Ctrl + Shift + → works.
  • Ctrl + ↑ or Ctrl + ↓ only moves the cursor for one line (it should move it for the entire paragraph).
  • Ctrl + Shift + ↑ or Ctrl + Shift + ↓ also doesn't work (it should move it for the entire paragraph and select the text).
  • Home works.
  • End doesn't work, instead of to the end of the line, it moves the cursor to the beginning of the next line (you need a paragraph with more than one line to see this).
  • Shift + Home, Shift + End works.
  • Ctrl + Home, Ctrl + End, Ctrl + Shift + Home, Ctrl + Shift + End work.
  • It happened to me a few times that the cursor just jumps at the end of the text, once while pressing End and a few times when pressing ↓.
  • Empty paragraphs behave weirdly: it is possible to make them, but they are not saved. Occasionally it is not possible to move cursor into them, neither by mouse nor by arrows.
  • When I select the text, the selection is lost if I right-click outside of the selection. This is not how the browser behaves.

Firefox 11.0 on Ubuntu 10.10.

Very weird:

  1. Make a new blank paragraph.
  1. Press Ctrl + ` (this is how I switch keyboard layout on one of my computers).
  1. Press Alt + Shift twice to change the keyboard layout to Serbian.
  1. Press ш.

ш appears at the cursor. A new paragraph is created above the current paragraph. ш also appear at the new paragraph, but is overwritten with the next letter I type. Doesn't happen every time, but I managed to trigger it multiple times.

(In reply to comment #9)

From

https://www.mediawiki.org/w/index.php?title=Visual_editor/Feedback&oldid=552919#CTRL.2BLeft_arrow_doesn.27t_work_as_expected

I was trying to use CTRL+Left arrow to move the cursor to the left, but it only
moves one character at time (instead of one word at time).
Curiously, it works fine for selection (i.e. CTRL+SHIFT+Left arrow).

The right arrow behaves the same way as the left one.

For the record, this test was done using Firefox 9.0.1 on Windows XP, but the same problem happens on Ubuntu 12.04 using either Chrome 19.0.1084.56 or Firefox 13.0.1.

This is fixed in current version of the Visual Editor.

And now it's broken again. Ctrl+left/right is moving one character at a time again.

(In reply to comment #16)

And now it's broken again. Ctrl+left/right is moving one character at a time
again.

What version of the code were you running? Some details about your browser set-up/etc. would be helpful to debug.

If you're talking about the version running on MediaWiki.org, note that is updated every fortnight and that it has not yet had this code go live.

What version of the code were you running? Some details about your browser
set-up/etc. would be helpful to debug.

If you're talking about the version running on MediaWiki.org, note that is
updated every fortnight and that it has not yet had this code go live.

Oh, sorry. I was indeed talking about the version on Mediawiki.org. The Mediawiki.org version now seems to have the issue resolved. (Is there a way to test just the most recent version of VisualEditor?)

Not on MediaWiki.org (as with other wikis, that runs the current deployed version). In the future we intend to have a labs machine running the live head, but that's not yet something we've built.

I'm also testing on mediawiki.org but these haven't been mentioned before so I don't believe they're fixed in git.

Various key combinations behave very weirdly for me.

  • Ctrl + ← or Ctrl + → works.
  • Ctrl + ↑ or Ctrl + ↓ doesn't move the cursor at all (it should move it

for the entire paragraph).

  • Ctrl + Shift + ↑ or Ctrl + Shift + ↓ also doesn't work (it should move it for

the entire paragraph and select the text).

  • Home works.
  • End works, but it moves the cursor to the right of the space after the last word on the line and not to the right of the last character of the last word of the line. This is how Notepad behaves, but not how Firefox behaves. I consider this to be a minor bug.
  • Ctrl + Home, Ctrl + End work.
  • Any selection: Shift + ←, Shift + →, Ctrl + Shift + ←, Ctrl + Shift + →, Shift + Home, Shift + End, Ctrl + Shift + Home, Ctrl + Shift + End or mouse selection selects appropriately, and creates the bold/italic/link menu icon; but then whatever I press (esc, arrow, etc.), the selected text is deleted.

Firefox 16.0.1 on Windows XP SP 2.

orbit wrote:

Nikola, thank you for such a thorough check. In this whole project, we've been balancing which features we allow the browser to do natively vs. which we handle programmatically. In this last release, we gave the power back to the browser for most cursor movement.

Ctrl + ↑ and Ctrl + ↓ don't have any native behavior in Firefox. We could programmatically move the cursor to the beginning or end of the paragraph though, but we'd handle it in a separate enhancement request.

With the End key issue that you described, again, we're letting Firefox do what it does natively.

The selection stuff is a huge goof on our part. I've got a fix committed and reviewed. We'll release to mediawiki.org in the morning.