784847 - Focusing text fields is flaky (regression)

Status: RESOLVED DUPLICATE of bug 784016

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

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

0) In portrait mode...
1) Open Firefox (17).
2) Go to https://bug708457.bugzilla.mozilla.org/attachment.cgi?id=597241
3) Click a field that would overlap the soft keyboard ("City:" on my Galaxy Nexus)

Expected: The soft keyboard is raised and the page is scrolled such that the clicked field is visible even with the raised soft keyboard.
Actual: The field is not selected and the soft keyboard is not raised.

I cannot repo this in landscape mode nor on tablet devices (I'm using a Galaxy Nexus). This happens only at the default zoom level. It happens on TouchPal and default IMEs. It is worth mentioning this works correctly in 16 so this is a regression of some sort.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Note: Old title is relevant to previous comment.

In fact, on the page above (step 2), input field selection is much flakier in 17 than in 16.

For example, on the Galaxy Nexus in portrait mode, from an initial page load, select "Address" and then while the soft keyboard is up, try to select "Last Name". In my testing, the soft keyboard always drops and no input fields are selected. However, this does not happen on 16.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

This is related to a bug I'm working on, bug 725018, so I will look into it, however, it would be greatly appreciated if someone already knew what changed. :)

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

FormAssistant.handleEvent in browser.js normally gets called when an input field gets focus. After including some debug statements, it appears that for both cases listed above, this method never gets called.

Working on finding the regression window...

Comment 4

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Regression-window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22288130fea2&tochange=86ee4deea55b

Both problems were broken and fixed in the same build.

Most likely cause is bug 780906.

Comment 5

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I tried backing out the patch from bug 780906 and it fixed the second case (comment 1), sometimes, and did not fix the first case (initial description).

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Michael Comella (:mcomella) from comment #5)
> I tried backing out the patch from bug 780906 and it fixed the second case
> (comment 1), sometimes...

Turned out I was pressing the wrong button and the backout fixed nothing. I'm going to try tbpl regression hunting now.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I got this:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=86ee4deea55b&tochange=1340cabb01d1

Which does not contain any of the changesets from the first regression-window... This makes me question whether I'm doing this correctly. However, this new window contains only the first changeset following the previous regression-window. It doesn't back out cleanly so it might be hard to test that way, but I will try to back it out.

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Not sure where I went wrong but I have the same results as this comment from bug 784016: https://bugzilla.mozilla.org/show_bug.cgi?id=784016#c14

I will look into a solution for bug 784016 and if it fixes this, I will mark it as a dupe.

Comment 9

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Solved by the patch in bug 784016.