Closed
Bug 811953
Opened 8 years ago
Closed 8 years ago
[keyboard] Submitting a form from a text field with the keyboard up persists the keyboard
Categories
(Firefox OS Graveyard :: General, defect, P2)
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)
People
(Reporter: jsmith, Assigned: ttaubert)
References
Details
Attachments
(2 files)
170.62 KB,
image/png
|
Details | |
1.60 KB,
patch
|
vingtetun
:
review+
|
Details | Diff | Splinter Review |
Build: Device - Unagi Hashes <project name="gaia" path="gaia" remote="b2g" revision="1c884f41292650615b04ca9f40cab981ea9e4d00"/> <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="76848b5c67e6c164b28f366534e5eeab8fcadc2a"/> Example Steps (although there's many ways to reproduce this): 1. Go to bugzilla.mozilla.org in the browser 2. In search text box above, type in a valid bug number and hit enter Expected The keyboard should disappear upon submitting the form to search. Actual The keyboard continues to persist post submitting the form and loading of the next page. As a result, the keyboard remains up while viewing the web content that was loaded.
Reporter | ||
Updated•8 years ago
|
blocking-basecamp: --- → ?
Ah! good catch! I was trying to figure this out yesterday. Apparantly if you hit the button on the page to submit it will not persist; if you hit return on the VKB it will persist. It only requires a submit form text field: going to http://people.mozilla.com/~nhirata/html_tp/formsninput.html , typing in the username field and then hitting return should show this issue as well.
Screenshot to show why it's a blocker; I ran into this with yesterday's build just by going to the FTU screen trying to type a password and then hitting the home button. I am easily able to reproduce this issue now.
Comment 3•8 years ago
|
||
Tim, I wonder if this is a regression from the recent keyboard changes. Can you take a look? Drivers, I would block on this because the keyboard is open and points to nowhere. It seems a broken feature.
Updated•8 years ago
|
blocking-basecamp: ? → +
Priority: -- → P2
Comment 4•8 years ago
|
||
this is also a blocker for FB Deep integration as this bug also happens in the FB Login page
Assignee: nobody → ttaubert
Reporter | ||
Updated•8 years ago
|
Component: Gaia → Gaia::System::Keyboard
Comment 5•8 years ago
|
||
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Target Milestone: --- → B2G C2 (20nov-10dec)
Assignee | ||
Updated•8 years ago
|
Status: NEW → ASSIGNED
Duplicate of this bug: 816052
Assignee | ||
Comment 9•8 years ago
|
||
Let's remove the focus change delay for now. For one, it doesn't actually work and the keyboard still fades in and out when changing input fields. Second, it's the cause of this bug. We should file a follow-up for switching input fields without a flickering keyboard but I think we should tackle this after bug 766066 that removes the ime-enabled-state-changed handler from forms.js.
Attachment #687049 -
Flags: review?(21)
Comment 10•8 years ago
|
||
Comment on attachment 687049 [details] [diff] [review] remove the focus change delay Review of attachment 687049 [details] [diff] [review]: ----------------------------------------------------------------- The logic could be done in Gaia to not show/hide the keyboard too fast.
Attachment #687049 -
Flags: review?(21) → review+
Duplicate of this bug: 817079
Keywords: checkin-needed
Comment 13•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/496c379c8d16
Keywords: checkin-needed
Comment 14•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/496c379c8d16
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•8 years ago
|
Component: Gaia::Keyboard → General
Comment 15•8 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/a22fef8e13ae https://hg.mozilla.org/releases/mozilla-beta/rev/2b31036aab8c
You need to log in
before you can comment on or make changes to this bug.
Description
•