Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Text editing behavior in BiDi is different between LeftArrow and Ctrl+LeftArrow #118

Open
PoignardAzur opened this issue Sep 23, 2024 · 6 comments
Open

Text editing behavior in BiDi is different between LeftArrow and Ctrl+LeftArrow #118

PoignardAzur opened this issue Sep 23, 2024 · 6 comments

Comments

@PoignardAzur
Copy link
Contributor

The easiest way to describe the problem is to show this snippet from the vello_editor example:

KeyCode::ArrowLeft => {
    self.selection = if ctrl {
        self.selection.previous_word(&self.layout, shift)
    } else {
        self.selection.previous_visual(
            &self.layout,
            self.cursor_mode,
            shift,
        )
    };
}

By default, pressing an arrow key moves your cursor in the visual direction of your key. But if you're doing ctrl+arrow, now the editor switches to "left means upstream, right means downstream". Both behaviors are mostly fine on their own (though "left means upstream" is latin-centric), but they're inconsistent with each other.

This behavior doesn't match either Chrome or Firefox.

(Parley's behavior with Home and End is also different from both Chrome and Firefox, but there's less of an inconsistency there, and Home/End support in BiDi is bad in both Chrome and Firefox anyway.)
@nicoburns
Copy link
Contributor

What is the behavious in Chrome/Firefox/other text engines?

@PoignardAzur
Copy link
Contributor Author

PoignardAzur commented Sep 23, 2024 •
edited
Loading

Chrome

Chrome fully commits to "The dir attribute is always right". This value is usually inherited from the <html> element. Which means if your page has a LTR direction, LeftArrow is always upstream and RightArrow is downstream. The opposite if your page has a RTL direction.

If you're selecting across elements with different directions, the anchor wins out.

Home and End go to the logical start and end no matter what.

Firefox

Firefox matches LeftArrow with visual left movements and vice versa. Doing so means the cursor's byte position may jump wildly when crossing BiDi boundaries.

This still applies when holding shift, but only in non-editable text.

For some reason, if you're holding Shift in editable text, Firefox goes "Screw you, left is upstream and right is downstream". As far as I can tell (from playing around with Yiddish Wikipedia) this applies no matter the page's default language and direction.

In all those cases, Ctrl+LeftArrow will go in the same direction as LeftArrow.

Here too, Home and End go to the logical start and end no matter what.

Now that I've taken the time to enumerate these behaviors, they don't seem that inconsistent.

Except for editing in Firefox. I suspect many RTL users just don't bother with Firefox, because this is strikingly annoying behavior.

@xorgy
Copy link
Member

xorgy commented Sep 23, 2024 •
edited
Loading

I think that the reason shift selection forces upstream/downstream in some browsers is a limitation around non-contiguous selections; or alternatively if you go the other way around, there is a case where a visual cursor at a direction boundary would result in a circumstance where none of the inner directionality text would be selected.

@xorgy
Copy link
Member

xorgy commented Sep 23, 2024

Chromium's behavior makes sense I think, though the visual behavior is attractive for implementation reasons.

In the application case we would go with the locale default directionality, but there's also a case that overriding it should be an option (though this gets complicated when locale data come from the environment, and may not be present for). This is a benefit of using the visual direction, because we already have the visual order of the text figured out for layout, without locale knowledge.

@PoignardAzur
Copy link
Contributor Author

I think that the reason shift selection forces upstream/downstream in some browsers is a limitation around non-contiguous selections; or alternatively if you go the other way around, there is a case where a visual cursor at a direction boundary would result in a circumstance where none of the inner directionality text would be selected.

I don't think so. Shift+Arrow works reasonably well in Firefox outside of editable text. I think this is a straight up bug.

@dfrg
Copy link
Collaborator

dfrg commented Sep 26, 2024

I believe the current state roughly matches the behavior of pango (or gedit). I have no objections to changing this.

This might be a good opportunity to discuss/document what our behavior should be and why we’ve decided as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dfrg @nicoburns @xorgy @PoignardAzur