Closed Bug 736008 Opened 13 years ago Closed 12 years ago

The autocomplete suggestion is detached from the textfield on some devices

Categories

(Firefox for Android Graveyard :: General, defect)

14 Branch
ARM
Android
defect
Not set
normal

Tracking

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

VERIFIED FIXED
Firefox 15
Tracking Status
firefox14 --- fixed
firefox15 --- verified
blocking-fennec1.0 --- +

People

(Reporter: AdrianT, Assigned: Margaret)

References

Details

Attachments

(3 files, 1 obsolete file)

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.
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: ? → -
Attached file more screenshots (obsolete) —
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)
Attachment #608508 - Attachment is patch: false
Attached image more screenshots
The last image managed to get messed up while uploading.
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+
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
(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.
(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.
(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
Closed: 12 years ago
Resolution: --- → DUPLICATE
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 → ---
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+ → ?
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: ? → +
Target Milestone: --- → Firefox 15
Blocks: 735734
Status: REOPENED → RESOLVED
Closed: 12 years ago12 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
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: