Closed
Bug 9041
Opened 25 years ago
Closed 25 years ago
User Password dialog ( and SS dialogs ) don't work
Categories
(Core :: Networking, defect, P1)
Tracking
()
M10
People
(Reporter: michaell, Assigned: gagan)
References
Details
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M9
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Component: Autofill → HTML Dialogs
Summary: Can't dismiss autofill box → Can't dismiss dialog box
Comment 2•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: morse → davidm
Status: ASSIGNED → NEW
Comment 4•25 years ago
|
||
David, is there any workaround for this for M8? Any page that requires
authentication will essentially hang the browser.
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•25 years ago
|
||
Okay, will release note.
Reassigning to don to see if this should be in m8
Assignee: davidm → don
Status: ASSIGNED → NEW
Priority: P3 → P1
Summary: Can't dismiss dialog box → User Password dialog ( and SS dialogs ) don't work
Target Milestone: M9 → M8
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 10•25 years ago
|
||
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.
Assignee | ||
Comment 11•25 years ago
|
||
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•25 years ago
|
||
*** Bug 6144 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 13•25 years ago
|
||
*** This bug has been marked as a duplicate of 6144 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 14•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
You need to log in
before you can comment on or make changes to this bug.
Description
•