Closed Bug 1402461 Opened 3 years ago Closed 3 years ago

.focus() not always open android keyboard

Categories

(Firefox for Android :: Keyboards and IME, defect)

57 Branch
All
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 58
Tracking Status
fennec + ---
firefox56 --- unaffected
firefox57 + fixed
firefox58 --- verified

People

(Reporter: y.brunelliere, Assigned: snorp)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached file focus.html
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122310

Steps to reproduce:

small test page in attachment

click button 1
then button 2
then button 3

nightly 2017-09-21 , android 7.0


Actual results:

1-focus is set in the input field, android keyboard show up
2-focus is set to the second button
3-focus is set in the input filed, no keyboard appears


Expected results:

1-focus is set in the input field, android keyboard show up
2-focus is set to the second button
3-focus is set in the input filed, android keyboard show up
Sorry, bug submitted on my computer, not phone.
Firefox build id on my phone is 20170921100140.

Typo in attachment, the third button should be "3 focus again"
Hi Jim
Is there anything I can do?
Or can you help? Thanks!
Flags: needinfo?(nchen)
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → All
See Also: → 1404111
Attached file Another testcase (obsolete) —
Turned the testcase from bug 1404111 into an alternative one for this one - clicking into the input field is enough to trigger the bug on recent builds.

As for your original testcase, it seems like the keyboard isn't triggered if the focus is on one of the buttons - if I remove the focus by clicking somewhere else within the page, then the next focus() call suceeds in triggering the keyboard.
Attached file Another testcase, v2
Attachment #8914508 - Attachment is obsolete: true
From my testing I found that the keyboard show only if there is no active element. (that's why it works only on first click or after you click the "body" element.


bluring the active element and then focusing on the new one does not work
document.activeElement.blur();
theinputfield.focus();


This very dirty code can be called  by the setInterval() Method :

if(document.activeElement.nodeName!="INPUT") document.activeElement.blur();

and the keyboard will show up every time.


I think the regression occured 1 or 2 week before my bug report.
(In reply to Jan Henning [:JanH] from comment #3)
> Created attachment 8914508 [details]
> Another testcase
> 
> Turned the testcase from bug 1404111 into an alternative one for this one -
> clicking into the input field is enough to trigger the bug on recent builds.
> 
> As for your original testcase, it seems like the keyboard isn't triggered if
> the focus is on one of the buttons - if I remove the focus by clicking
> somewhere else within the page, then the next focus() call suceeds in
> triggering the keyboard.

Yes it seems to me bug 1404111 is very very related.
Clicking the div sets it as the active element.
The JS puts the focus on the input field.
No keyboard because there was an active element.
[Tracking Requested - why for this release]: Keyboard cannot be opened on some pages

@Snorp: Caused by bug 1400878, I'm afraid. Before your patch, I'm still seeing buggy behaviour with my testcase (https://bugzilla.mozilla.org/attachment.cgi?id=8914517), but that fixes itself if the tab/Firefox is momentarily backgrounded. After your patch, the I'm unable to trigger the keyboard at all.
Blocks: 1400878
Flags: needinfo?(snorp)
No longer blocks: 1400878
Depends on: 1400878
Flags: needinfo?(snorp)
Comment on attachment 8914911 [details]
Bug 1402461 - Improve user input detection for focus changes in Fennec r=jchen

Jim Chen [:jchen] [:darchons] has approved the revision.

https://phabricator.services.mozilla.com/D94#1976
Attachment #8914911 - Flags: review+
Assignee: nobody → snorp
Status: NEW → ASSIGNED
Flags: needinfo?(nchen)
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1f53b54ca629
Improve user input detection for focus changes in Fennec r=jchen
https://hg.mozilla.org/mozilla-central/rev/1f53b54ca629
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Hmm, I think that your change is not good for other platforms. I think that you could've added a new bool flag like mIsUserInput to InputContextAction and made IMEStateManager set it before notifying widget of that.
tracking-fennec: ? → +
Duplicate of this bug: 1404111
Duplicate of this bug: 1405403
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #11)
> Hmm, I think that your change is not good for other platforms. I think that
> you could've added a new bool flag like mIsUserInput to InputContextAction
> and made IMEStateManager set it before notifying widget of that.

Should this be a new bug so it doesn't get lost?
Flags: needinfo?(snorp)
Flags: needinfo?(masayuki)
Yep, filed a followup.
Flags: needinfo?(snorp)
Comment on attachment 8914911 [details]
Bug 1402461 - Improve user input detection for focus changes in Fennec r=jchen

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1400878
[User impact if declined]: Buggy keyboard behavior on some sites
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: Yes, run the second testcase from this bug and ensure the keyboard comes up when the input field is focused.
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Small change, only affects a specific instance where we did not correctly recognize user input was present.
[String changes made/needed]: None
Attachment #8914911 - Flags: approval-mozilla-beta?
Duplicate of this bug: 1405078
Comment on attachment 8914911 [details]
Bug 1402461 - Improve user input detection for focus changes in Fennec r=jchen

Recent regression, Beta57+
Attachment #8914911 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Julien Cristau [:jcristau] from comment #14)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #11)
> > Hmm, I think that your change is not good for other platforms. I think that
> > you could've added a new bool flag like mIsUserInput to InputContextAction
> > and made IMEStateManager set it before notifying widget of that.
> 
> Should this be a new bug so it doesn't get lost?

Yes, and...

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #15)
> Yep, filed a followup.

Thank you for filing the bug.
Flags: needinfo?(masayuki)
Based on comment 16 and the second test case: verified as fixed on latest Nightly build.
Device: Motorola Nexus 6 (Android 7.1.1), Huawei MediaPad M2 (Android 5.1.1), Samsung Galaxy Tab 3 (Android 7.0).
You need to log in before you can comment on or make changes to this bug.