353648 - Master password sometimes sheet, sometimes dialog

Status: RESOLVED DUPLICATE of bug 1149505

(Core :: Widget: Cocoa, defect, P1)

Description

[TGOS]

Sorry if that is a duplicate, but if it is, the real issue has such a poor description or tagging that I can't find it.

If Thunderbird is the front-most app and it needs the master password (in my case directly after launch), the dialog appears as a "sheet". But if I switch to another app while Thunderbird is still loading and it then requests my password while this other app is front most, the dialog is in fact a "dialog" (own window) and not a sheet.

Not only this is inconsistent (I see no reason for such a behavior) and not only that I don't know of any other Macintosh app that would behave this way, it also has two drawbacks:

1) If I then bring Thunderbird to front, to enter my master password, the main window goes to front, the dialog not (it's not a model dialog in the eye of the system and still it blocks the front window), the dialog will be behind the main window! So I have to move the main window aside or use Expose, otherwise I can't focus the dailog.

2) If an app, that is not front-most opens up a sheet, it bounces at least once in the dock or multiple times on the Mac on catch the user's focus, like "Hey, here is something that needs your attention". This never happens at the moment. And even if you'd make it happen (programatically), clicking on the app in the dock will cause me to run into issue (1). So I miss entering the master password on time, the IMAP connection to my mail server times out because I have not authenticated on time, no new mails are fetched. Very bad mojo.

My idea of how to fix it: Master password is always and at any time a sheet, no matter if front most app or not and when not front most app, application bounces in dock till it gets user's attention. That would be a lot more Apple like IMHO.

Comment 1

[Mitar]

I can confirm this behavior. And I have also noticed that it is possible that even two non-sheet password dialog prompts are displayed what makes everything really messy.

Comment 2

[Joseph Delaney]

Also affects version 2.0PR1

Worst part of  this is described in scenario #1 of the original report. When this happens thunderbird seemingly "hangs" - it's actually waiting for the password but since the password prompt is not visible and there is no other feedback, it's essentially dead to someone who doesn't know to move the main window. Before I realized what was happening I continually force-quit the application. 

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This issue can still be seen with Thunderbird 2.0.0.8pre under Mac OS X. Running my debug version of Thunderbird 3 doesn't show it anymore. You always get a sheet displayed. The described issue with multiple windows also don't occur.

David, was there a code change on trunk?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Same happens for Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

If you start Firefox in background while another application is in front no sheet but a dialog is placed behind the active window. If you click somewhere inside the Firefox window (not at the password dialog) the dialog is placed behind Firefox and cannot be accessed until you minimize the main window.

Whether a user starts Firefox/Thunderbird in foreground or background we should use a sheet to ask the user to enter his master password.

Comment 5

[Justin Dolske [:Dolske]]

I see this a fair amount, when I'm restoring a FF session and one tab has a login form on it, resulting in a master password prompt (so password manager can fill in the form).

This only seems to happen during startup, trying to trigger this by opening from and external app (eg, click a link in Thunderbird) always gives me a sheet.

Loading a page that calls prompt() or alert() works fine, even via session restore. It's always a sheet. [http://people.mozilla.org/~dolske/testcase/353648/alert.html and .../prompt.html]

I vaguely remember the sheet/dialog thing happening during a browsing session (after startup), but I don't think that's happened in a long time, so whatever was causing that might have been fixed except for the during-startup case?

The master password prompt is invoked from PK11PasswordPrompt() in /security/manager/ssl/src/nsNSSCallbacks.cpp. It's just using nsIPrompt, which seems fairly ordinary.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I stepped through the code and noticed that there is a difference. If another application has the focus during the startup of Firefox there is returned a NULL pointer by GetActiveWindow:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp&rev=1.38&mark=837-840&#822

If Firefox is the active window we get the correct pointer. Due to we don't have a parent a dialog is shown.

Justin, this could be caused by the same situation you described in bug 409975 comment 1.

Comment 7

[Erik Rose [:erik][:erikrose]]

Here's a really twisted manifestation: the Master Password modal dialog appeared, and I ignored it for awhile. Later, Firefox got really impatient and showed another copy of it: as a sheet inside the initial modal!

Comment 8

[Jim Mathies [:jimm]]

for investigation

Comment 9

[Stephen A Pohl [:spohl]]

It looks like bug 1149505 will address this.