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)
Tracking
(firefox14 fixed, firefox15 verified, blocking-fennec1.0 +)
VERIFIED
FIXED
Firefox 15
People
(Reporter: AdrianT, Assigned: Margaret)
References
Details
Attachments
(3 files, 1 obsolete file)
190.39 KB,
image/png
|
Details | |
145.94 KB,
image/png
|
Details | |
2.69 KB,
patch
|
mfinkle
:
review+
blassey
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
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•13 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
Updated•13 years ago
|
blocking-fennec1.0: --- → ?
Updated•13 years ago
|
blocking-fennec1.0: ? → -
Assignee | ||
Comment 3•13 years ago
|
||
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•13 years ago
|
Attachment #608508 -
Attachment is patch: false
Assignee | ||
Comment 4•13 years ago
|
||
The last image managed to get messed up while uploading.
Assignee | ||
Updated•13 years ago
|
Attachment #608508 -
Attachment is obsolete: true
Comment 5•13 years ago
|
||
Noming again based on the new screenshots showing worse behavior
blocking-fennec1.0: - → ?
Updated•13 years ago
|
Assignee: nobody → margaret.leibovic
blocking-fennec1.0: ? → beta+
Assignee | ||
Comment 6•13 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
Comment 7•13 years ago
|
||
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.
Assignee | ||
Comment 8•13 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?
Comment 9•13 years ago
|
||
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•13 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!
Comment 11•13 years ago
|
||
Recommend not blocking beta for this.
Assignee | ||
Comment 12•13 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.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 14•12 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•12 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•12 years ago
|
||
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)
Updated•12 years ago
|
Attachment #617946 -
Flags: review?(mark.finkle) → review+
Comment 17•12 years ago
|
||
This bug was beta+ and was re-nomed. Setting blocking+ to get the compromise patch in ASAP.
blocking-fennec1.0: ? → +
Assignee | ||
Comment 18•12 years ago
|
||
Target Milestone: --- → Firefox 15
Comment 19•12 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Comment 20•12 years ago
|
||
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?
Updated•12 years ago
|
Attachment #617946 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 21•12 years ago
|
||
status-firefox14:
--- → fixed
Comment 22•12 years ago
|
||
Verified fixed in current trunk on the Galaxy Nexus. Much better now.
Status: RESOLVED → VERIFIED
status-firefox15:
--- → verified
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•