1353294 - Password capture doorhanger loses focus on navigation while editing within it

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

Mac OS 55.0a1 (2017-04-03) (64-bit)

STR:

1. go to website with password form
2. enter username and password
3. firefox asks to save in the panel
4. focus username field in panel
5. web page form submission happens and new page loads

Expected: focus remains in browser chrome panel where i'm editing

Actual: panel remains open but focus is gone from panel - something in page was able to steal it from browser chrome.

Comment 1

[Johann Hofmann [:johannh]]

Afaict this sounds a bit more dramatic than what's really happening. The popup notification indeed loses focus on navigation, which is annoying, but the focus remains on the Chrome window. Bug 1334496 might help here. I'll try that later.

Dietrich, do you have a POC where it is actually possible to move focus into the content window while the doorhanger is open? I hacked this demo together in a couple of minutes, there might be more ways to steal focus: http://output.jsbin.com/guhiyoduli

Comment 2

[Dietrich Ayala (:dietrich)]

> Bug 1334496 might help here. 

That bug seems to be focused (ha!) on the reverse situation: Making the popup steal focus from content in certain situations.

> Dietrich, do you have a POC where it is actually possible to move focus into
> the content window while the doorhanger is open? I hacked this demo together
> in a couple of minutes, there might be more ways to steal focus:
> http://output.jsbin.com/guhiyoduli

No, I just noticed on Mozilla's business card service, which I hadn't logged into in years, so needed to update my password. Thanks for making that test case!

Comment 3

[Johann Hofmann [:johannh]]

Alright, thanks for reporting!

Comment 4

[:garvan]

I am trying http://output.jsbin.com/guhiyoduli, and I see the input elements flicker at the 2 second mark, but the doorhanger keeps focus. I was expecting the doorhanger to lose keyboard focus.

Comment 5

[:garvan]

Oops, I just re-read this bug and my own comment 4 made little sense to me.
I meant to say more clearly: I don't see the bug using the jsbin page from comment 1.
My statement 'I was expecting the doorhanger to lose keyboard focus' === I was expecting to see the bug and did not.
The flicker I mentioned is my visual cue that perhaps the dialog lost and regained focus, but is not a bug in itself.

Comment 8

[Dietrich Ayala (:dietrich)]

Just an update that the bug still occurs on latest nightly.

Maybe worth noting:

It seems like I see this at times when I see the doorhanger pop up and there's a password but no username.

I go to enter a username, and while doing so, focus goes away as the page navigates.

Comment 9

[Johann Hofmann [:johannh]]

Matt, is this something your team would be interested in? :)

Comment 10

[Matthew N. [:MattN]]

Yes, but the doorhanger isn't a focus at the moment.

Comment 11

[Dietrich Ayala (:dietrich)]

I see this pretty regularly now - perhaps because of recent changes in how the popup is activated?

I've noticed I see the popup (or at least the blue key icon?) much earlier in account creation flows - maybe triggering off email entry or something like that.

It seems like I see this at times when I see the doorhanger pop up and there's a password but no username.

I go to enter a username, and while doing so, focus goes away as the page navigates.

This is still when I see it most, and it just happened again on a page that was slow and had multiple load/redirects (appeared to, anyway).

Annoying, as I'm trying to type something and focus keeps going away whilst doing so.

Seems like an active+focused privileged input field should never be able to have focus stolen by something happening that was triggered by content.

In an attack scenario, a page could listen to key events and have a non-zero chance of capturing something you were typing into a privileged field.

Comment 12

[Dietrich Ayala (:dietrich)]

In an attack scenario, a page could listen to key events and have a non-zero chance of capturing something you were typing into a privileged field.

Hm, if focus is going to other chrome-priv'd field as Johann said above, then no.

Comment 13

[Dietrich Ayala (:dietrich)]

Just saw it again signing in to notarize.com.

Again it was the popup with password populated but no username.

I start typing the username and mid-way the focus is gone so my key events are going... somewhere?

The fact that it happens at all is a UX problem.

If the key events are going to content, it could be a more serious problem.

Low criticality maybe, but user input meant for chrome should never be going to content.