Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122604 Minefield/3.0b3pre ID:2007122604 The master password sheet is a document modal dialog and should be displayed within the same window as Apple describes: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/20000961-TPXREF11 Normally it's working fine but if Firefox slows down e.g. caused by bug 407821 it can happen that the master password sheet is opened inside the wrong window. For my case I had open the Library Window. Steps to reproduce: 1. Set a master password 2. Save a password from a website 3. Lets Firefox forget master password 4. Open the Library window 5. Slow down the system or Firefox 6. Open website again and switch to Library window immediately The master password dialog appears inside the Library instead of the normal browser window where user input should be locked until the password was entered correctly or the dialog canceled. It seems that we specify the active window as parent?

PK11PasswordPrompt() in nsNSSCallbacks.cpp() doesn't specify a window parent when prompting (first arg): rv = proxyPrompt->PromptPassword(nsnull, promptString.get(), &password, nsnull, nsnull, &value); This eventially ends up in nsPromptService::DoDialog(), which does: if (!aParent) { mWatcher->GetActiveWindow(getter_AddRefs(activeParent)); aParent = activeParent; } I doubt the callbacks way down in the PSM/PKCS11 guts have any way of knowing what window (if any) is associated with the call.

PSM is supposed to pass a context handle into NSS whenever the call might trigger a password prompt callback. This context object is supposed to be given as the void*arg to the callback. Right now we are using type PipUIContext. Maybe this type could be enhanced to carry a window? Maybe each context using it could attempt to determine the current window and adding it to the context object. The callback could make use of the window stored in the object, when available.

reassign bug owner. mass-update-kaie-20120918

This should be fixed by bug 1149505 (i.e. making the password dialog/sheet not be modal).