Closed Bug 733907 Opened 12 years ago Closed 12 years ago
Typing text into a crossword on the Times Crossword does not move across different text boxes
Steps: 1. Go to http://crossword.thetimes.co.uk/ 2. Select a crossword to open to start playing 3. Select a text box in the crossword that has text boxes to sides of them 4. Start typing text Expected: After I type a character into a text box, the cursor to type text should move to the next applicable place to type. Actual: After I type a character into a text box, I stay within the same text box. Note that this is incorrect behavior for a crossword, as typically as you type a character, you move to the next applicable box. In comparing this to the stock browser and desktop firefox, both of them follow the expected behavior. Device: Samsung Galaxy Tab Builds: Fennec Native 12 Aurora & Fennec Native 13 Nightly
Whiteboard: [gecko] [topapps] [website-compatibility]
what is the behavior on desktop with an IME?
Desktop IME has the same problem.
Component: IME → Event Handling
Product: Fennec Native → Core
QA Contact: ime → events
Version: Firefox 12 → Trunk
Assignee: nobody → masayuki
The problems I see on the Mac desktop are a little different than what I see on Fennec, but I believe this is a bug in Gecko core or the content itself. * On Fennec, entering characters will cause multiple characters to appear in a single box. * With Mac's built-in IME, a new composition string's first clause will overwrite the current box's character and then move the cursor to the next box for the composition string's remaining characters. * With Mac's "Special Characters" window, only the first inserted character appears in the box and the cursor does not move to the next box.
btw, the "Special Characters" problem is a content bug because I can reproduce it with Chrome and Safari on Mac. With Mac's built-in IME, though, Chrome and Safari seem to work correctly, but they do not move the cursor to the next box after committing the composition string.
I can reproduce this problem on Google Chrome on Windows with Japanese IME. Why do we need to fix this? Isn't this a bug of the web site if we cannot hide this bug by bug 687717's patch?
I can reproduce this on Mac Chrome and Safari. Can we close this as "not our bug"?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
My fix for bug 687717 makes this problem go away for Fennec users inputting Latin characters using VKB.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.