736008 - The autocomplete suggestion is detached from the textfield on some devices

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Adrian Tamas (:AdrianT)]

Attachment: autocomplete suggestions

Fennec/14.0a1 2012-03-14
Device: HTC Desire (Android 2.2.2)

Steps to reproduce:
1. Open Nightly.
2. Go to mail.yahoo.com or gmail.com.
3. Save a few valid or invalid username/password combinations.
4. Reload the page and start typing a username.

Expected results:
The autocomplete suggestions appear as a dropdown list attached to the input field.

Actual results:
If there is no text in the input field - like when loading the page after restart - the autocomplete is displayed over the text field.
When the user starts to filter the autocomplete suggestions by typing characters the dropdown is detached from the input field.

Notes:
 I was only able to reproduce the issue on the HTC Desire. I was unable to reproduce the issue on Motorola Droid Pro (Android 2.3.3), HTC Desire Z (Android 2.3.3) or LG Optimus 2X ( Android 2.2)

Comment 1

[Martijn Wargers (dead)]

I can resproduce this with this simple testcase too:
http://people.mozilla.com/~mwargers/tests/forms/autocomplete_forms/textinput_form.html
After a couple of times entering a character that keeps the autocomplete popup open, then pressing the del key, blurring the input and then focusing again reproduces it for me.

Comment 2

[:Margaret Leibovic]

I can also reproduce this on a Motorola Atrix (2.3.4). It seems like we're sending the position data from Gecko before the page is done rendering, so the data is wrong, but I've also seen it happen after the page is done loading. Maybe this is a regression from the maple landing, since we're using viewport data to calculate the position of the popup. We should investigate this more.

Also, I think Brian reproduced this on a Droid Razr.

Comment 3

[:Margaret Leibovic]

Attachment: more screenshots

mfinkle mentioned to me that this got blocking-fennec1.0- because it didn't look too bad, but I've seen the popup appear in some pretty bad positions. When working on the form validation popup, there were some cases where it was off screen, but I couldn't reproduce that now. Here are some screenshots I was able to come up with just now.

Motorola Atrix (2.3.4)

Comment 4

[:Margaret Leibovic]

Attachment: more screenshots

The last image managed to get messed up while uploading.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Noming again based on the new screenshots showing worse behavior

Comment 6

[:Margaret Leibovic]

Kats, this appears to be a problem with viewport data, and I'm wondering if you know what could be causing this (or if you know who to talk to). We're computing the data to position the popup in _getElementPositionData here:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#3038

I added some logging in here to see what was going on, and visited http://people.mozilla.org/~mwargers/tests/autocomplete_forms/textinput_form.html on my Atrix (incorrectly positioned popup) and my Galaxy Nexus (correctly positioned popup), and I found the viewport.y value makes an extreme change after typing more than one character in the input box. The zoom also changes when you start typing, but I believe that's expected (or if not, it's not causing this positioning problems). Here are the results of my logging:

Motorola Atrix (2.3.4):

Tap on element to focus (popup appears):
rect (x, y, w, h): 8, 8, 507, 51
viewport (x, y, zoom): 0, 0, 0.6703042
computed (x, y) values: 8, 8

Type one character (popup still showing):
rect (x, y, w, h): 8, 8, 507, 51
viewport (x, y, zoom): 0, 0, 0.99990124
computed (x, y) values: 8, 8

Type another character (popup still showing):
rect (x, y, w, h): 8, 8, 507, 51
viewport (x, y, zoom): 0, -318, 0.99990124
computed (x, y) values: 8, 326.0314087819313

Galaxy Nexus (4.0.2):

Tap on element to focus (popup appears):
rect (x, y, w, h): 8, 9, 563, 50
viewport (x, y, zoom): 0, 0, 0.7346938775510204
computed (x, y) values: 8, 9

Type one character (popup still showing):
rect (x, y, w, h): 8, 9, 563, 50
viewport (x, y, zoom): 0, 0, 0.9999615
computed (x, y) values: 8, 9

Type another character (popup still showing):
rect (x, y, w, h): 8, 9, 563, 50
viewport (x, y, zoom): 0, 0, 0.9999615
computed (x, y) values: 8, 9

Comment 7

[Kartikaya Gupta (email:[e-mail])]

This sounds like it's related to bug 732016. I'm surprised that it's happening only after typing the second character though, I would have expected it to happen right when you focus on the element. One thing you can try is commenting out the "frameLoader.clampScrollPosition = false;" line in browser.js and seeing if that makes this problem go away. If it does, then it's definitely caused by bug 732016.

Comment 8

[:Margaret Leibovic]

(In reply to Kartikaya Gupta (:kats) from comment #7)
> This sounds like it's related to bug 732016. I'm surprised that it's
> happening only after typing the second character though, I would have
> expected it to happen right when you focus on the element. One thing you can
> try is commenting out the "frameLoader.clampScrollPosition = false;" line in
> browser.js and seeing if that makes this problem go away. If it does, then
> it's definitely caused by bug 732016.

Yep, commenting that line out makes the problem go away. Is this bug a dupe, then?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

I guess you could mark it as a dupe if you want. Thus far I've just been leaving bugs open and marking them as dependent on 732016, to be verified and closed once that gets fixed.

Comment 10

[:Margaret Leibovic]

(In reply to Kartikaya Gupta (:kats) from comment #9)
> I guess you could mark it as a dupe if you want. Thus far I've just been
> leaving bugs open and marking them as dependent on 732016, to be verified
> and closed once that gets fixed.

Okay, let's leave it open then. Thanks for your help!

Comment 11

[Erin Lancaster [:elan]]

Recommend not blocking beta for this.

Comment 12

[:Margaret Leibovic]

(In reply to Erin Lancaster from comment #11)
> Recommend not blocking beta for this.

This should be fixed by bug 732016, so there isn't really anything to do here anyway. We're just keeping it open to verify.

Comment 14

[Adrian Tamas (:AdrianT)]

The issue is still reproducible on Nightly/14.0a1 2012-04-22 after the fix for Bug 732016 has landed. The issue is reproducible after the suggestions are displayed and the user enters one character to filter the suggestion. Reopening the issue in order to be tracked separately.

Comment 15

[:Margaret Leibovic]

I don't think this needs to block beta, but should probably soft block (or block final if we find some sites where the positioning is really bad).

There are two different issues going on here. The first issue will be fixed by bug 732016, and it's the issue that made this into a beta blocker.

1) Because of bug 732016, we're getting bad viewport x/y coordinates, and this can make the popup appear way off, as shown in the screenshots.

2) We're showing the popup when the input is focused, and if that focus happens before the page is done loading, we don't have the right zoom level data when we show the popup. The mispositioning that results from this problem is less severe, and this only happens for inputs that are focused while the page is loaded

I started working on a patch to handle the zoom/viewport data in Java, hoping that will make it easier to fix this. Kats suggested using something similar to PanZoomController.getRedrawHint() to check if we're zooming, but I found that PanZoomController's mState is NOTHING when we show the popup, so the problem seems to just be that we're not done setting the viewport metadata by the time we decide to show the popup.

(Also, if we fix bug 725018, we may want to figure out how to preserve the suggestions when zooming in on the input field, but that's a separate issue that doesn't exist yet)

Comment 16

[:Margaret Leibovic]

Attachment: Show autocomplete suggestions on click instead of on focus

This takes care of problem 2 because we won't show the autocomplete suggestions anymore if we receive a focus event while the page is loading. Although a user could theoretically tap on an input while the page is still drawing, it seems like we won't run into that problem as much.

Comment 17

[Mark Finkle (:mfinkle) (use needinfo?)]

This bug was beta+ and was re-nomed. Setting blocking+ to get the compromise patch in ASAP.

Comment 18

[:Margaret Leibovic]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5ed25c2f2aed

Comment 19

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/5ed25c2f2aed

Comment 20

[JP Rosevear [:jpr]]

Comment on attachment 617946 [details] [diff] [review]
Show autocomplete suggestions on click instead of on focus

Mobile blocker, should be mobile only.

Comment 21

[:Margaret Leibovic]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8fb4d0f15a18

Comment 22

[Martijn Wargers (dead)]

Verified fixed in current trunk on the Galaxy Nexus. Much better now.