Password dialogs unresponsive (sp3)
 

(Sp1 did this too.)

Issue: A browser password dialog (eg, the .htaccess type) becomes unresponsive if it spawns from a window during either a workspace loading or OW launching in the background.

How to recreate: Go to a site that requires such a dialog (eg, [url]http://forums.omnigroup.com/[/url]) Save that workspace (if it doesn't autosave) and quit OW.

Relaunch OW and click off to another app. Shortly thereafter the dialog will come to the front and be either partially or completely unresponsive. Sometimes I can type in a username, sometimes I cannot. Cancel, okay, clicking on the input fields or trying to tab through yields no results. Only way out is to force quit.

Anyone else seen this issue?

I had a single related experience with SP1.

From time to time I'm asked for my username & password when entering this forum -- perhaps 3-4 times out of 50-some visits.

One time I switched to my Omni Forums workspace, which had three forum directory pages saved as tabs in a single window. The username/password dialog sheet appeared from the active page, with a free-floating u/p dialog on top of the window (offset from the dialog sheet).

I was able to fill in the dialogs. When I completed the free-floating one, another appeared. All was well after submitting my username & password three times.

I attached a screenshot to the bug report I submitted by email.

-- Ward

A few minutes ago I was once again prompted for username & password upon opening my OmniWeb workspace, although this time I had five tabs ... and five requests.

I was smarter this time: I responded to the top request with the beta group's username & password, and I canceled the rest. Then I selected each tab and clicked the Refresh button.

Aside: Each time I've filled in this dialog, I've checked the Save in Keychain option. This works fine on other Basic Auth sites, but not here. Hmmm.

-- Ward