The current implementation of visual word movement collects word breaks matching the Windows specification: |abc |def |ghi| (LTR block) where | indicates positions of word breaks. The Mac/Linux specification defines word boundaries when going left: |abc |def |ghi| (LTR block) and when going right: |abc| def| ghi| (LTR block) This blocks on https://bugs.webkit.org/show_bug.cgi?id=65277, as a fix to 65277 would allow a flexible way to select whether the next word boundary should be logically before or after a word given the editing behavior, box direction, and block direction.
I should rephrase: This block *practically depends* on https://bugs.webkit.org/show_bug.cgi?id=65277.
*** This bug has been marked as a duplicate of bug 85017 ***