New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug-Regression



Sign in to add a comment
link

Issue 780834: Password saver sends misleading blur/focus events

Reported by 93m...@gmail.com, Nov 2 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Steps to reproduce the problem:
1. Find a page with a form (e.g. https://www.konstella.com/signin.html)
2. Enter a username and password
3. Save it to the password manager
4. Load the attached extension, which runs:

var log = function(event){
  console.log(event.type, event.target, document.activeElement);
  return true;
};
window.addEventListener("focus", log, true);
window.addEventListener("blur", log, true);

5. Reload the page

What is the expected behavior?
blur/focus events correspond to changes in focus.

Expected output:
blur
[initial document.activeElement]
[input-1]
focus
[input-1]
[input-1]
blur
[input-1]
[input-2]
...
focus
[input-n]
[input-n]
blur
[input-n]
[initial document.activeElement]
focus
[initial document.activeElement]
[initial document.activeElement]

What went wrong?
Each autofilled element in the form is sent a focus event and a blur event in turn. document.activeElement does not change

Moreover, document.activeElement doesn't receive a blur event before this, nor a focus event after. This is confusing for scripts using focus/blur to track changes in the focused element.

This affects the Vimium extension, as described in https://github.com/philc/vimium/issues/2549.

Did this work before? Yes 

Does this work in other browsers? N/A

Chrome version: 62.0.3202.75  Channel: stable
OS Version: 
Flash Version:
 
password-manager.zip
522 bytes Download

Comment 1 by manoranj...@chromium.org, Nov 2 2017

Labels: Needs-Triage-M62 Needs-Bisect

Comment 2 by divya.pa...@techmahindra.com, Nov 3 2017

Components: UI>Browser>Passwords
Labels: Triaged-ET Needs-Feedback
Unable to test this scenario as seeing no sign up option on https://www.konstella.com/signin.html to test and confirm this. Adding proper component for someone from the respective team for help in further investigation of this 

However tried by logging in Facebook page, unable to reproduce the issue on reported version  62.0.3202.75 latest Canary 64.0.3256.0. 

Attaching screen-cast for reference
FB.ogv
6.2 MB View Download

Comment 3 by 93m...@gmail.com, Nov 3 2017

> Unable to test this scenario as seeing no sign up option on https://www.konstella.com/signin.html to test and confirm this.

You can fill in the boxes and then press the key button in the address bar. You don't need to log in or submit the form at any point.

> Attaching screen-cast for reference

It doesn't look like you've looked at the log in developer tools, which is where the extension logs the relevant information. You can press <esc> or choose the console tab in developer tools to show the log.

Comment 4 by sheriffbot@chromium.org, Nov 3 2017

Project Member
Cc: divya.pa...@techmahindra.com
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by kolos@chromium.org, Nov 3 2017

Status: WontFix (was: Unconfirmed)
When Chrome fills a field, Chrome generates a bunch of Javascript events (https://codereview.chromium.org/2750323003, https://codereview.chromium.org/1955963002/) to notify the site about changes. 

In some cases, sites needs onBlur and OnFocus. But unfortunately sometimes these events may confuse sites.

Comment 6 by 93m...@gmail.com, Nov 3 2017

The blur and focus events aren't a problem per se, but is it massively out of reach to send a blur event to the active element before and a focus one after? If there are events being spoofed anyway, another couple to bring Chrome back into line with the spec and expectations would be a tidy fix.

Obviously spoofing document.activeElement asking the way would be helpful, but it's not a showstopper like the inconsistent events are.

Comment 7 by battre@chromium.org, Nov 3 2017

Cc: se...@chromium.org
Labels: -Pri-2 -Needs-Bisect Pri-3
Status: Available (was: WontFix)
CCing sebsg, who worked on getting most of the events in place in https://codereview.chromium.org/1955963002/ already

Comment 8 by se...@chromium.org, Nov 4 2017

Owner: se...@chromium.org
Ah I didn't think of that when I made the change since when you autofill an address or a card you are necessarily focused on the field.

So if I blur the active element and focus on it at the end, that would fix your problem right?

Comment 9 by 93m...@gmail.com, Nov 4 2017

It would, yes. Thanks for taking a look at this.

Comment 10 by se...@chromium.org, Nov 14 2017

Status: Started (was: Available)

Comment 11 by to...@lamr.org, Nov 23 2017

We are experiencing probably the same issue (since Chrome 62) https://forums.smartclient.com/forum/smart-gwt-technical-q-a/250270-lost-focus-with-chrome-linux

It breaks several users' apps.

Comment 12 by se...@chromium.org, Nov 23 2017

Labels: Needs-Feedback
Hum, I'm surprised the issue is only found starting in 62. This would mean that it's not my old change mentioned in the above comments that's causing the issue since I had made that more than a year ago.

Can you confirm that it started failing in M62?

Comment 13 by to...@lamr.org, Nov 23 2017

Our scenario is that user clicks on date picker, and small calendar is shown where they can select date&time.

Just downgraded to (debian 9) 61.0.3163.100-1~deb9u1, I can observe the additional focus event is happening just once. Since then, it never happens again.

However with 62.0.3202.89-1~deb9u1, it happens everytime user opens the date picker (and causing subsequent picker close).

We have a single shared picker for whole app, hence this was probably unnoticed for some time, but definitely 62 made it worse.

Comment 14 by se...@chromium.org, Nov 23 2017

Hum, I read the article in the forum and this seems to be unrelated to my change especially as it applies specifically to Linux. Would you mind opening a different bug and linking the article again? Thanks!

Comment 15 by to...@lamr.org, Nov 23 2017

right, they discuss is only for Linux but we are seeing in on all MacOs, Win and Linux boxes. Both Chromium and Chrome.

Comment 16 by se...@chromium.org, Nov 23 2017

I would still open another bug, and if you give a website example a tester should be able to bisect and find a culprit.

I ask you this because I'm working on a solution for the bug in the title on this thread, but it won't fix your issue.

Comment 18 by h.wib...@gmail.com, Nov 24 2017

I am running into this as well. We have a single page app and the password field stays in the DOM but is inside a hidden div. It keeps on triggering focus events that confuses other parts of the application that rely on knowing the currently focused object (which we keep track of by handling the focus event).

Comment 19 by se...@chromium.org, Nov 30 2017

Owner: ----
Status: Available (was: Started)
Transferring to the Password folks. I seems strange that it all started going bad in version 62, because the code for the focus and blur is much older.

One solution might be to simply not send these events for Password Autofill.

Otherwise it could be interesting to figure out what changed in version 62 that now causes all these issues.

Comment 20 by se...@chromium.org, Nov 30 2017

Cc: vabr@chromium.org kolos@chromium.org dvadym@chromium.org

Comment 21 by vabr@chromium.org, Dec 1 2017

Cc: krajshree@chromium.org
 Issue 788190  has been merged into this issue.

Comment 22 by h.wib...@gmail.com, Dec 1 2017

Not sure if it matters, the reported OS is 'Linux' but I see this on Windows (10) as well..

Comment 23 by vabr@chromium.org, Dec 4 2017

Thanks for pointing that out! In general, all desktop platforms (Linux, Windows, Mac and Chrome OS) use the same code. There are minor differences, but I believe emitting the events should be the same on all four of them (likely also on Android).

Comment 24 by 93m...@gmail.com, Dec 8 2017

> One solution might be to simply not send these events for Password Autofill.

This would be a great to do, at least until blur/focus events and document.activeElement are consistent with normal behaviour.

> Otherwise it could be interesting to figure out what changed in version 62

The original issue I reported here predates 62, in case looking into this prevents progress.


For reference, Vimium no longer uses the focus event to track changes in focus to avoid this bug.

Comment 25 by se...@chromium.org, Jan 8 2018

Cc: ma...@chromium.org
 Issue 788189  has been merged into this issue.

Comment 26 by vabr@chromium.org, Jan 9 2018

Cc: -vabr@chromium.org

Comment 27 by s...@hinderlingvolkart.com, Mar 14 2018

This issue seems to have been fixed with v64 (although I don't see any update in this ticket). We can still see focus events on autofill, but not anymore this obviously faulty behaviour where this would happen again and again every time a form element was added to the DOM.

Comment 28 by gongd...@gmail.com, Sep 24

@sebsg The problem that Password Saver dispatches "unexpected" events still exists on Chrome 69, and keeps to make webpages and extension error-prone.

On June 28, 2017, I filed an issue on https://github.com/philc/vimium/issues/2549 to report those unexpected focus/blur events. As far as I've tested, this issue has begun since Chrome 59 (while Chrome 62 is just what 93m...@gmail used), and also occurs on v60, ..., 68 and 69.

I have read comments above and noticed that in the latest `WebFormControlElement::SetAutofillValue`, some extra plain events including `keydown` and `keyup` are sent, which seems to make things worse for Vimium-like extensions - because it notify those extensions a key is pressed, but nobody knows which key is sent, both `event.key` and `event.keyCode` are even `undefined`.

So, I wonder if Chrome could modify its behavior to match the common spec. Thanks anyway.

====

BTW, I find some tricks(?) when testing the auto-filling behavior:
* `F5` is not recommended, because Chrome (v69 on win10 x64) remembers which part of the tab is currently focused;
* therefore, one of the best way is to create a new tab (using an extension or by clicking an `<a href target=_blank>`),
  and the Password Saver will auto fill inputs with tons of events being dispatched.
* and one result of my tests is in the attachment.
example-of-pw-saver-actions.jpg
101 KB View Download

Sign in to add a comment