Comment 115 for bug 195698

I can verify that typing one's master password fast enough will avoid the problem, but one must type very very very quickly. One of the frustrating things about thsi bug for me is that more often than not, another master password dialog arrives and steals the bloody keyboard focus, even though the z-order of the new dialog with keyboard focus is below the dialog in which one was just typing. So you end up searching for the dialog with keyboard focus or trying to find a dialog that will accept the keyboard focus because sometimes the edit control seems to be blocked for some of the multitude of master password dialogs.

I see this as a security issue because one ends up blindly retyping one's master password without verifying that it is actually ending up where intended. My feeling is that the master password request should be queued, and only repeated if the previous attempt failed, or if the master password has timed-out for some reason. The password dialog should be replaced by an interface element that exists in the status bar, or the URL edit control or whatever it's called as long as it is made explicitly clear that a request is being made for the master password. The point being that this functionality should be something that cannot be faked by nasty web pages or rogue extensions (regardless of whether anything could be done with the snarfed password).