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!

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.

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.

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

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

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.

(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?

Yep, filed a followup.

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

Comment on attachment 8914911 [details] Bug 1402461 - Improve user input detection for focus changes in Fennec r=jchen Recent regression, Beta57+

(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.

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).