The autocomplete suggestion is detached from the textfield on some devices

VERIFIED FIXED in Firefox 14

Status

()

VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: AdrianT, Assigned: Margaret)

Tracking

14 Branch
Firefox 15
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox14 fixed, firefox15 verified, blocking-fennec1.0 +)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
Created attachment 606140 [details]
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)
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.
(Assignee)

Comment 2

7 years ago
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.
Summary: The autocomplete suggestion is detached from the textfield on the HTC Desire → The autocomplete suggestion is detached from the textfield on some devices
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → -
(Assignee)

Comment 3

7 years ago
Created attachment 608508 [details]
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)
(Assignee)

Updated

7 years ago
Attachment #608508 - Attachment is patch: false
(Assignee)

Comment 4

7 years ago
Created attachment 608511 [details]
more screenshots

The last image managed to get messed up while uploading.
(Assignee)

Updated

7 years ago
Attachment #608508 - Attachment is obsolete: true
Noming again based on the new screenshots showing worse behavior
blocking-fennec1.0: - → ?
Assignee: nobody → margaret.leibovic
blocking-fennec1.0: ? → beta+
(Assignee)

Comment 6

7 years ago
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
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.
Depends on: 732016
(Assignee)

Comment 8

7 years ago
(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?
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.
(Assignee)

Comment 10

7 years ago
(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!
Recommend not blocking beta for this.
(Assignee)

Comment 12

7 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 732016
(Reporter)

Comment 14

7 years ago
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 15

7 years ago
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)
blocking-fennec1.0: beta+ → ?
(Assignee)

Comment 16

7 years ago
Created attachment 617946 [details] [diff] [review]
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.
Attachment #617946 - Flags: review?(mark.finkle)
Attachment #617946 - Flags: review?(mark.finkle) → review+
This bug was beta+ and was re-nomed. Setting blocking+ to get the compromise patch in ASAP.
blocking-fennec1.0: ? → +
(Assignee)

Comment 18

7 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ed25c2f2aed
Target Milestone: --- → Firefox 15
Blocks: 735734

Comment 19

7 years ago
https://hg.mozilla.org/mozilla-central/rev/5ed25c2f2aed
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Comment on attachment 617946 [details] [diff] [review]
Show autocomplete suggestions on click instead of on focus

Mobile blocker, should be mobile only.
Attachment #617946 - Flags: approval-mozilla-aurora?
Attachment #617946 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed in current trunk on the Galaxy Nexus. Much better now.
Status: RESOLVED → VERIFIED
status-firefox15: --- → verified
Comment hidden (spam)
You need to log in before you can comment on or make changes to this bug.