A right- (or center-) aligned TextField jumped to the left the moment
editing started, because the native inline editor ignored the field's
horizontal alignment on Android and in the JavaSE simulator. iOS already
honored it (CodenameOne_GLViewController.m maps alignment 3->right, 4->
center), so those two ports drifted out of sync and produced the visible
jump (and, with a hint, a right-aligned hint next to a left-placed cursor).
Android (InPlaceEditView): set the EditText gravity from the field's
absolute alignment instead of only flipping on isRTL(). The value is
snapshotted into TextAreaData on the CN1 EDT (new absoluteAlignment field)
so it is read safely off the EDT like the other cached properties.
JavaSE simulator (editString): set the single-line Swing editor's
horizontal alignment (JTextField / JPasswordField) from the field's
absolute alignment. getAbsoluteAlignment() already resolves LEFT/RIGHT for
RTL, so the prior RTL behavior is preserved.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Problem
Editing a right-aligned decimal
TextFieldmade the number jump to the left the moment editing started (issue #5370). With a hint set it was worse: the hint stayed pinned to the right while the cursor appeared on the left, which is easy to miss.Root cause
When a field is edited, Codename One overlays a native inline editor and hides the lightweight component. The idle lightweight render honors the field's
RIGHTalignment, but the native editor's horizontal alignment is decided per-port — and the ports were out of sync:CodenameOne_GLViewController.mmaps alignment3 → NSTextAlignmentRight,4 → center), fed fromgetStyle().getAlignment(). No jump.InPlaceEditView) — set gravity fromisRTL()only, never from alignment → always left for non-RTL.editString) — built a plainJTextFieldand never calledsetHorizontalAlignment→ Swing default leading/left.So on Android and in the simulator a right/center-aligned field always left-aligned during editing, producing the visible jump. This is longstanding behavior, not a recent regression on the horizontal axis (the recent #5345/#5358 change was about vertical alignment).
Fix
Bring Android and the simulator in line with iOS by driving the native editor's horizontal alignment from the field's
getAbsoluteAlignment()(which already resolves LEFT/RIGHT for RTL, so the previous RTL behavior is preserved).EditTextgravity from the alignment. The value is snapshotted intoTextAreaDataon the CN1 EDT (newabsoluteAlignmentfield) so it is read safely off the EDT, consistent with the other cached properties.JTextField/JPasswordField). Multi-lineJTextAreahas no per-line horizontal alignment in Swing and is unaffected (not part of this issue).Testing
mvn -Plocal-dev-javase -pl javase compile— green.mvn -pl android compile— green.Closes #5370.
🤖 Generated with Claude Code