"Store password" dialog box freezes input system-wide while it is up

UNCONFIRMED
Unassigned

Status

()

Core
Widget: Gtk
P2
normal
UNCONFIRMED
3 months ago
13 days ago

People

(Reporter: Alain Knaff, Unassigned, NeedInfo)

Tracking

52 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170613225334

Steps to reproduce:

1. Went to a page with a password form (for which I had not logged in so far)
2. Entered user name and password



Actual results:

3. A  dialog box appeared asking me to store the password
4. Complete system became unresponsive to mouse and keyboard actions (mouse pointer still moved, but applications didn't react to input such as scroll wheel)


Expected results:

3. A  dialog box appeared asking me to store the password (this step is ok)
4. System should continue to behave normally, and let me work.


Maybe that freeze is necessary for security (but why exactly? This doesn't happen on password input, but _after_ password has been entered!), but security in one application should not be reached by decreasing security everywhere else.

This bug makes debugging web applications with login forms a pain.
If this behavior is intentional (I hope it isn't), who comes up with such ideas?

Updated

3 months ago
Component: Untriaged → Notifications and Alerts
Product: Firefox → Toolkit
(Reporter)

Comment 1

3 months ago
Feeling that the window manager should not actually allow such disruptive behavior, I reported the bug on KDE's bug tracker, and I was told that this is actually a (mis)feature of X11 directly, which the window manager cannot even block: XGrabKeyboard

After a bit of searching, I happened upon this workaround: https://bugs.freedesktop.org/show_bug.cgi?id=21652#c4

It "solves" the issue, without any negative side effects. I feel firefox should not attempt to use such "forgotten" APIs to disrupt other applications. Apparently, the reason why this XGrabKeyboard API still exists and still is effective (rather than being re-mapped to a no-op) is for the benefit of screen savers, which could otherwise be subverted with the right key combos. The intention is certainly NOT to allow browsers to play games with their users.
Thanks for the report.

(In reply to Alain Knaff from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Build ID: 20170613225334
> 
> Steps to reproduce:
> 
> 1. Went to a page with a password form (for which I had not logged in so far)
> 2. Entered user name and password
> 

This was a form in a webpage for an HTTP auth dialog?

> Actual results:
> 
> 3. A  dialog box appeared asking me to store the password

Was this the doorhanger that appears anchored from the address bar?

> 4. Complete system became unresponsive to mouse and keyboard actions (mouse
> pointer still moved, but applications didn't react to input such as scroll
> wheel)
> 
> 
> Expected results:
> 
> 3. A  dialog box appeared asking me to store the password (this step is ok)
> 4. System should continue to behave normally, and let me work.
> 
> 
> Maybe that freeze is necessary for security (but why exactly? This doesn't
> happen on password input, but _after_ password has been entered!), but
> security in one application should not be reached by decreasing security
> everywhere else.
> 
> This bug makes debugging web applications with login forms a pain.
> If this behavior is intentional (I hope it isn't), who comes up with such
> ideas?

This isn't intentional.
Component: Notifications and Alerts → Widget: Gtk
Flags: needinfo?(mozilla)
Product: Toolkit → Core
(Reporter)

Comment 3

a month ago
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #2)
> Thanks for the report.
> 
> (In reply to Alain Knaff from comment #0)
[...]
> > 1. Went to a page with a password form (for which I had not logged in so far)
> > 2. Entered user name and password
> > 
> 
> This was a form in a webpage for an HTTP auth dialog?

A form in a web page.

> 
> > Actual results:
> > 
> > 3. A  dialog box appeared asking me to store the password
> 
> Was this the doorhanger that appears anchored from the address bar?

No, it appears anchored from the form field

[...]
> > This bug makes debugging web applications with login forms a pain.
> > If this behavior is intentional (I hope it isn't), who comes up with such
> > ideas?
> 
> This isn't intentional.

That's reassuring. Thanks :-)
Flags: needinfo?(mozilla)

Comment 4

13 days ago
I don't sere a call to XGrabKeyboard in our source so I'm not sure about the reported cause here. 

CXn you provide some information on your distro and set up?
Flags: needinfo?(mozilla)
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.