Text input bugs of the Android backend and the Skia renderer #7203
Comments
wuwbobo2021
added
bug
|
This issue can be split into two parts. One part is what I'm fixing in the PR, it consists of the wrong cursor index calculation bug and Another problem is related to the panic logging in the initial post: Eventually I discovered that it is a bug of the skia renderer (which is the only renderer for Android), not the Android backend. I've reproduced it on Windows. Add the fn main() -> Result<(), slint::PlatformError> {
let selector = slint::BackendSelector::new().renderer_name("skia".to_string());
if let Err(err) = selector.select() {
panic!("Unable to select the skia render: {err:?}");
}
slint::slint!{
import {Button, GroupBox, TextEdit, LineEdit} from "std-widgets.slint";
export component MainWindow inherits Window {
width: 300px;
height: 200px;
VerticalLayout {
LineEdit { text: "Hello"; }
TextEdit { text: "Line 1\nLine2\nLine3\n"; }
}
}
}
let main_window = MainWindow::new()?;
main_window.run()
}Run it and switch to some input method that distinguishes "preedit" text from existing text, type a few characters at the middle of existing text, some mark like underline will appear for the "preedit" text; then click on a position beyond the end of the whole text to produce the crashing. This can be found easily on Android because the input method exists for English. On PC, some input method of other languages may be installed to reproduce the problem. Note:
|
|
I added an index checker in I have found another possible Unicode problem with the preedit feature (while changing cursor position).
But this is not eliminating the invalid index from its source, and the text input is still buggy without crashing (try to modify some text and you'll realize some problems), I am frustrated... |
|
Sorry. I have tested some emoji (stored by a pair of Java primitive After recovering the previous The crashing is still produced when editing non-ASCII text if my character boundary checker is removed from Note for the description "anything typed into it may disappear after losing focus" in the first post: it's probably not a problem, because the text that disappears is always the preedit text in the input method. Sometimes the underline isn't shown, though. |
|
Added notes: This bug can be produced after removing the character boundary checker Put "úī " in the text input, type "a" in the default (English) input method as the preedit text, set the cursor before 'ú' then after 'ú', then it will panic at The "characters cannot be typed into the text input anymore" problem should be seperated from this bug: it can be observed without triggering the panicking described above while using Google Pinyin input method (either Chinese mode or English mode, difficult to produce under English input method); the problem remains after switching to the English input method, before forced-stopping and restarting the application. It cannot be reproduced on PC with the Skia renderer. I am not sure whether it is a bug inside Slint. Observed with the character boundary checker added in the PR: My assertion added after |
wuwbobo2021
changed the title
LineEdit and TextEdit on Android
|
Without the PR #7204, the clipboard operation crashing problem and the "soft input always prompt out" exist on Android 6.0 and 8.0, but they may not be reproduced on Android 11.0. Both problems aren't related to the skia renderer. Line 527 indicated by the stack trace does I've found a similar issue: xamarin/Essentials#820, https://github.com/MicrosoftDocs/xamarin-docs/pull/1812/files. |
ogoffart
added
a:renderer-skia
Bug Description
Tested on Android 11.0, and Android 6.0 (the later requires my modified version to run it), without
SLINT_STYLEoverride.LineEditis almost unusable because the left side of the text selector often appears and sticks at the left side, then anything typed into it may disappear after losing focus.When editing text in
TextEdit, it is easy to trigger application crashing (the log is provided below). Even if it does not crash, it may still produce strange insertion beyond the cursor location. It seems like a bug of character index calculation.Reproducible Code (if applicable)
The text was updated successfully, but these errors were encountered: