Closed Bug 1090034 Opened 10 years ago Closed 10 years ago

Keyboard is mistakenly hidden when switch input focus between system and app

Categories

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: timdream, Unassigned)

References

Details

The bug is cloned to input mgmt because of the cause found in bug 1083617 comment 9. The STR is the same. It might only affects switching between two input types. +++ This bug was initially created as a clone of Bug #1083617 +++ STR: 1. Go to any app, say Contact -> New Contact, and focus on an input field, e.g. Phone number. 2. Tap on the Rocket bar ("Search the web") to switch the focus to the rocket bar. 3. Type something Expected: 1. The input caret moved to rocket bar, and the layout switch to Search w/o auto suggestions. Actual: 1. Sometimes the caret remained in the Contact app frame, sometimes the caret does moved to search field but the layout is not switched, sometimes everything visually correct but you can't type anything. Note: I suspect this is a regression of bug 1057898, bug 1067264, and bug 1067266, but it's worthy to check if InputMethod API is previously shown this behavior already. qawanted for v2.1 check. I have a patch (see bug 1077124 comment 11) that would bring back the race protection in the keyboard app (the delay removed in bug 1067264). I will file a bug blocks this one to land it. We can decide whether or not we need to revert the behavior of input mgmt later, as the visual effect (have the keyboard start slide away in midway and slide back instantly) can be fixed in CSS with bug 1075306. I would still like to keep bug 1057898 in the tree for switching inputs between the same frame.
We would need to fix both bug to make the STR go away.
Summary: Focus between two frames will fail in both keyboard and InputMethod API, affecting Rocketbar → Keyboard is mistakenly hidden when switch input focus between system and app
See Also: → 1083617
:mnjul, Looks like we either need to bring back bug 1067266 or we need something smarter in input management. Could you dig deeper on this bug when bug 1083617 is fixed? Alternatively I can give you an Gecko with bug 1083617 locally applied.
Flags: needinfo?(jlu)
I am sorry, this bug is invalid, see bug 1083617 comment 12.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(jlu)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.