Bugzilla – Full Text Bug Listing
| Summary: | non composable key combinations erases first char in text editors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Henrik Lindberg <henrik.lindberg> | ||||
| Component: | SWT | Assignee: | Scott Kovatch <skovatch> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Silenio Quarti <Silenio_Quarti> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, eclipse.felipe, skovatch, thomas | ||||
| Version: | 3.6 | Flags: | Silenio_Quarti:
review+
|
||||
| Target Milestone: | 3.6.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Henrik Lindberg
Works for me using 3.6 RC4 on Windows XP and Linux GTK. Didn't test on Mac. I'm using a Swedish keyboard and I see different behavior on Linux and Windows. On Linux, a composed character is created when I type ~ followed by = (the tilde is above the equal sign). On windows this doesn't happen. If I switch to US keyboard on Linux, this behavior is gone. So my conclusion is that it is not just related to what platform you're on. It's also locale dependent. I used a Swiss German keyboard. what build are you running ? (In reply to comment #0) > Reproducible: Always. > Reproduce by: > - Open a text editor (I tested in Java, as well as in Xtext generated editors): > - Type ~ > - Type = > > Result, the ~ is deleted. Expected result: "~=" What keyboard layout are you using? With the layouts I've tried (US, Spanish, Swiss German) I see a different behavior that's still wrong, but not as described: - Switch to the Spanish layout - Type option - ';', which gives the tilde and puts the editor in composition mode - Type = For Swiss German, you still type option-N to get a tilde, but the behavior is otherwise identical. Result: Composition mode ends and the cursor is located after the ~. The = keystroke is lost. Compare to TextEdit, which cancels composition mode and inserts the '='. >Result: Composition mode ends and the cursor is located after the ~. The =
>keystroke is lost.
I have a Swiss German keyboard and use Swiss German layout and there it works as expected i.e. the result is: ~=
I have a Swedish MacBookPro Keyboard. Restating the problem: In text editors eclipse deletes a compose sequence that should result in two separate characters. Another sequence that fails is: ¨ (diaeresis) followed by 1 That ought to trigger the problem irrespective of keyboard layout as I don't think there exists a language that has a digit with diaeresis. So if you type diaresis followed by a one, you get the one? On Linux I get nothing at all (everywhere, not just Eclipse). (In reply to comment #9) > So if you type diaresis followed by a one, you get the one? On Linux I get > nothing at all (everywhere, not just Eclipse). No, 'diaeresis' followed by '1' produces a 'diaeresis' followed by a '1' (i.e. *both* characters) on a mac - everywhere except in Eclipse text editors. The issue is that text editors does not follow the platform policy (at least not on mac :)) (In reply to comment #10) > > No, 'diaeresis' followed by '1' produces a 'diaeresis' followed by a '1' (i.e. > *both* characters) on a mac - everywhere except in Eclipse text editors. > > The issue is that text editors does not follow the platform policy (at least > not on mac :)) Okay, now I've got it. You're describing the same behavior as I wrote up in comment #5. I don't see the behavior of the first character after the dead key being deleted; it's just ignored. It's still a bug, but I want to make sure we're in agreement on what bug we're describing here. :-) For what it's worth, AWT text input on the Mac for Swing has the same bug. I now know what's going on but I'm not sure how to fix it. Normally Control.insertText is called once per keystroke but in this scenario it gets called twice: once to insert the diaeresis, and once to insert the '1'. The first time through Control.insertText(), s.keyInputHappened is set to true. On the second call to insertText we skip generation of KeyDown events because keyInputHappened was checked a few lines above. I need to look into why insertText needs to be checking this field. It should definitely set it, but I'm not sure it needs to be testing it. Created attachment 171593 [details]
Fix
In insertText, don't check for keyInputHappened before sending events. That field is a stop-gap in the event view.interpretKeyEvents() didn't generate anything.
Silenio, please review for 3.6.1. Looks good. Fixed in HEAD and 3.6 branch > 20100706. |