Open Bug 1329333 Opened 8 years ago Updated 2 years ago

autocomplete becomes visually detached from field

Categories

(Toolkit :: Form Manager, defect, P3)

53 Branch
defect

Tracking

()

mozilla52
Tracking Status
firefox52 --- wontfix
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix

People

(Reporter: tanvi, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [passwords:fill-ui])

Attachments

(1 file)

https://irccloud.mozilla.com/file/pAROSJmq/Screenshot%202017-01-03%2012.05.19.png Ryan found this bug in Nightly 53. The drop down from the form field is not attached to the field itself. This may not have to do with the insecure password warning, and may be an autocomplete issue in general. We need to figure out the regression window. What is the behavior in 50, 51, 52, 53. Save two usernames/passwords in the password manager and then test the site http://kindredcocktails.com/. Click on the username field and see where the drop down exists (attached or unattached to the form field)
Adrian, can you take a look at this and figure out what Firefox versions are affected? Thank you!
Flags: needinfo?(adrian.florinescu)
Blocks: 1329356
Priority: -- → P1
Whiteboard: [fxprivacy]
Target Milestone: --- → mozilla52
I've tried to identify a solid STR for this bug in order to get a regression range, but I only managed to get intermittent reproduction pattern. With normal steps I couldn't reproduce it on Ubuntu 16.04 / Mac 10.10 / Windows 10. (53/52/51.) I managed to reproduce it accidentally while I was trying to get a screen cast for another bug and only then I got the autofill to look like in :tanvi's screenshot. (maybe a focus related issue?) Further iterations related to this failed. I'll leave the NI on me until I can figure out how to reproduce it on a solid basis.
Priority: P1 → P2
Hi I tested this issue over and over and I think I have some steps. I can reproduce it with github.com on Mac, Windows and Ubuntu, with the site from description I wasn't able to. It might be an edge case but here are the steps: 1. Open https://github.com/login 2. Create 2-3 user entries. 3. Open again https://github.com/login and click on username (a dropdown with users appears) 4. Reload the page with F5, you need to push fast and many times. Please also note that this issue is reproducible intermittently. In some cases I reload the page one time and the bug appears but in other cases I need to reload many times the page until I see the bug.
Flags: needinfo?(adrian.florinescu)
Assuming this is a straight-up dupe of Bug 1336753, here is a fully reliable STR: 1. Go to an insecure webpage containing a password field (e.g., http://www.w3schools.com/html/tryit.asp?filename=tryhtml_input_password) 2. Open the browser console 3. In the browser console, enter the following code: > var box = gBrowser.getNotificationBox(); setTimeout(function(){box.appendNotification('banner','Example Banner','chrome://browser/skin/Info.png',box.PRIORITY_WARNING_MEDIUM, []);}, 5000); 4. Within 5 seconds, click on the username field. The contextual feedback should appear warning about insecure submission of passwords. 5. Wait for the notificationbox (yellow banner) to appear 6. Note that the username field has slid down, but the contextual feedback has not. The username field is now obscured and effectively impossible to use.
Intermittent issue, but annoying enough to users that there are a few duplicate bugs filed. Marking this fix-optional for now. Devin, leaving this to you if you'd like to investigate the underlying problem.
Our team won't be able to look at existing Toolkit bugs like this one for a while. But, it definitely makes sense to, and certainly appreciate, keeping this open and prioritized for when we can.
Flags: needinfo?(devinreams)
Component: Password Manager → Form Manager

This was made slightly more visible with the View Saved Logins autocomplete footer since it means we auto-open the popup in more cases.

I have attempted to reproduce this issue with the steps from any of its duplicates. The login page of Atlassian found is bug 1405077 seems to constantly reproduce the issue. It appears as... the password manager's drop-dows gets displayed, then something changes on the page (elements move) and the drop-down remains in the initial, currently improper position considering the movement of the fields. I do not believe that this issue is the same issue as some of the other duplicates. I have attempted to see if this issue (on Atlassian login page) can be regressed, but it seems like not a regression: firefox60, firefox55 reproduce the issue, and firefox50 does not show the drop-down.

I also remember some similar issue reproduced while testing the password manager feature, but I could not find steps that would reproduce it constantly. I will also deem this issue intermittent.

Whiteboard: [fxprivacy] → [passwords:fill-ui]
Flags: qe-verify+
Attached video QQ.com (deleted) —

Here is a more visible and visually unpleasant case on qq.com.

We shouldn't be triaging this in "regression triage" so please don't keep marking it affected for new versions.

Blocks: 1589795

The form validation popup already handles zoom and scroll changes. I'm not sure if there is anything to share with it: https://searchfox.org/mozilla-central/rev/cce8b90aece0f42e5025e45282de16066eeaa662/browser/actors/FormValidationParent.jsm#129-138

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #20)

The form validation popup already handles zoom and scroll changes. I'm not sure if there is anything to share with it: https://searchfox.org/mozilla-central/rev/cce8b90aece0f42e5025e45282de16066eeaa662/browser/actors/FormValidationParent.jsm#129-138

Need to somehow monitor for position changes of the input and trigger a rerender when it moves.

Severity: normal → S3
Priority: P2 → P3

The severity field for this bug is relatively low, S3. However, the bug has 13 duplicates.
:sgalich, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sgalich)
Flags: needinfo?(sgalich)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: