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.

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

TextField and TextArea don't behave natively #46

Open
5Mixer opened this issue May 26, 2020 · 5 comments
Open

TextField and TextArea don't behave natively #46

5Mixer opened this issue May 26, 2020 · 5 comments

Comments

@5Mixer
Copy link
Contributor

5Mixer commented May 26, 2020

Expected Behavior

  • Control + arrow keys should move cursor word by word
  • Control + a should select all text
  • Control + c should copy to the clip board
  • Control + v should paste from the clip board

Current Behavior

  • Control + arrow keys move cursor by single character
  • Control + a does nothing
  • Control + c does nothing on HTML5 and segfaults on linux (though I believe the segfault is Kha and not HaxeUI)
  • Control + v does nothing

Steps to Reproduce (for bugs)

  1. Use a HaxeUI app with a TextField
  2. Try keyboard combos shown in 'expected behaviour'

Test app / minimal test case

Kha HaxeUI skeleton with <textfield placeholder="Test" width="100%">
should be sufficient.

Context

Search box for searching assets in application does not behave as expected.

Your Environment

  • Version used: git
  • Environment name and version (e.g. Chrome 39, node.js 5.4): hxcpp / Kha git
  • Operating System and version (desktop or mobile): Arch Linux
  • Link to your project: Closed Source
@5Mixer
Copy link
Contributor Author

5Mixer commented Jun 15, 2020

Noticed another non-native quirk:
If long text is written in a textfield (that is, text longer than the width of the text field), input behaves as expected. Backspace behaves as expected, deleting characters before the cursor, until the start of the visible line is reached (that is, no characters are visible in the field, but more characters exist before where the cursor is).

Holding backspace visually does nothing at that point (when it is expected to show more text being removed), but after a period 'cuts' to a full line of text. I need to investigate this more so I can tell you more precisely how this is working. Edit: It seems like textfields normally work by fixing the rightmost character to the right of the textfield when the text is longer than the field width (keep in mind things like moving to the middle of the string are possible though).

Emulating native behavior is tricky, and certainly feels strange as a user when it doesn't work quite right. I'll have finished the bulk of my exams in a week and will hopefully be able to contribute some code, at least for Control+A etc.

@ianharrigan
Copy link
Member

Nice one, ill have a stab at these soon (weekend probably - maybe sooner)

@5Mixer
Copy link
Contributor Author

5Mixer commented Jun 19, 2020

No worries. I've created a fork and have gotten started. I have Control+A working.

Just noting another issue I found and will try to fix: Clicking 'shift' removes a selection. Natively, tapping shift and not moving the caret does nothing.

The issue is caused by

switch (code) {
    case Shift:
        _selectionInfo.start.row = _caretInfo.row;
        _selectionInfo.start.column = _caretInfo.column;
        _selectionInfo.end.row = _caretInfo.row;
        _selectionInfo.end.column = _caretInfo.column;
        _shift = true;

in onKeyDown.

Edit: Adding a simple if (!hasSelection) surrounding that shift reset code fixed the problem.

I wonder if the movement code Up/Down/Left/Right can be cleaned. I'll have a think about it.

@ianharrigan
Copy link
Member

Do we think this is closable now?

@5Mixer
Copy link
Contributor Author

5Mixer commented Jun 27, 2020

The initial problems are fixed, but text components don't yet behave natively.

  • Clicking and dragging doesn't create a selection, it only moves the caret.
  • Double and triple clicking doesn't select the word and paragraph - this feels less important than being able to select with the mouse, but is certainly standard native behaviour.
  • There is a bit of a hack in using Kha's scheduler to mitigate an issue with caret placement when inserted text starts to overflow outside component. It's functional, but if possible it would be good to diagnose and fix the underlying issue.

These are the immediate things I see, obviously all only tangential to the keyboard based improvements I initially proposed. As I said in Discord, I'm happy to try and work on these in a couple of days, or open these in a new issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants