9041 - User Password dialog ( and SS dialogs ) don't work

Status: VERIFIED DUPLICATE of bug 6144

(Core :: Networking, defect, P1)

Description

[Michael La Guardia]

Build #1999062909

I appear to have the Autofill feature enabled.  I browse to Bugzilla via the
link on the personal toolbar, and what looks like an autofill window pops up
over the half-loaded page.  This box never gets fully populated.  I cannot
dismiss this box.  Even if I hide the box, I still cannot access any links on
the page behind the box.

If I hide the box, and then position the cursor in the location field and hit
return to initiate a reload, the whole page appears to load, but I cannot access
any links.  The only things that appear to be live and working in the chrome are
the "home" and "my netscape" links.  When I click the "my" link, I go to the
home page, but no links there are active.  If I hide this window and then come
back to it, Seamonkey displays the half-loaded bugzilla page with the banner ad
from the home page.

Opening a new browser window does not help matters.

Comment 1

[Stephen P. Morse]

Yes, I just discoved this bug myself earlier in the week and was about to open a
report on it.  It is definitely a regression.

Here are the conditions under which it occurs.  If you are going to a login page
for which you have already saved username/password, and you haven't yet unlocked
your database in the current session, you are supposed to get a dialog asking
for your database password.  You are probably on the netlib thread at this time
and that is why the dialog is hanging.  But I can't explain why it used to work
unless the threading has been changed.

In any event, I can't fix it yet because the necko landing will change the
threading again.  So let me offer you a work-around -- if you have enabled
single signon, then make sure you manually unlock your database before going to
any site for which you have previously saved username/password.  You can force
such an unlock in several ways -- the simplest is to go to the signon viewer
(edit/wallet/view-signons) and delete at least one of the saved signons that you
see there.

BTW, the problem is only with single-signon -- never with wallet.  The reason is
that wallet never tries to fill in automatically but rather does so when the
user manually presses a button.  So this is not on the network thread.  Single
signon does so automatically when you return to a page for which you previously
saved.  And the fill-in would be seamless (no dialog) provided the data base had
already been unlocked.

Comment 2

[Stephen P. Morse]

Hey, this is more general than autofill -- I just tried going to a site for
which you need to be authenticated and I got the same behavior.  That is, a site
that puts up a username/password dialog box before it lets you enter.  If you
don't know any such sites, try
http://www.w3.org/P3P/Group/Syntax/Drafts/WD-P3P-19980814/syntax.html.

A bit of history here.  Whenever such a site is visited, the browser puts up a
login form.  I used to have a call to single signon at that point so that I
could put up (and capture) such logins.  But apparently it was not working
because the call was being done on the netlib thread.  So davidm removed my
single-signon call (in mkaccess.c)and used code in the network module to put up
this dialog safely.  And that had been working the last time I tried it.  But
just now when I tried it even davidm's safe dialog no longer works.

So this is more serious than wallet/single-signon.  Somebody changed something
very recently that broke all such dialogs.  Reassigning to davidm since this is
now in his domain.  Also changing the title to remove the mention of autofill
and changing the component from autofill to html dialog.

Comment 3

[davidm]

Assign but I am not going to look at it until after necko lands.

Comment 4

[Paul MacQuiddy]

David, is there any workaround for this for M8? Any page that requires
authentication will essentially hang the browser.

Comment 5

[davidm]

Besides using a Mac I don't have a solution. I am sure it is something in netlib
and I don't want to look at until after necko lands

Comment 6

[Paul MacQuiddy]

Okay, will release note.

Comment 7

[davidm]

Reassigning to don to see if this should be in m8

Comment 8

[don]

David says we really can't fix this the right way until Necko lands.  Anything
else is just another band-aid that will no doubt break again the next day.  Move
this to M9 for now ...

Comment 9

[davidm]

*** Bug 10119 has been marked as a duplicate of this bug. ***

Comment 10

[davidm]

I am reassigning to Necko because as far as I can tell Necko is never calling
the FE to put up the dialog. I have bugs on the other dialog issues in this bug.
If this is untrue, please point me towards the code that asks for the dialog.
	And for what its worth I'll be checking in new dialog code in the next couple
of days and I'll do a post with all the details of how to use it.

Comment 11

[Gagan]

I am going to have to mark this for post M9. Since we need to finish up some
more critical bugs for M9 first. And the deadline is tonite!!

Comment 12

[Warren Harris]

*** Bug 6144 has been marked as a duplicate of this bug. ***

Comment 13

[Warren Harris]

*** This bug has been marked as a duplicate of 6144 ***

Comment 14

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.