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.
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.
Component: Autofill → HTML Dialogs
Summary: Can't dismiss autofill box → Can't dismiss dialog box
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.
Assign but I am not going to look at it until after necko lands.
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
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 ...
*** Bug 10119 has been marked as a duplicate of this bug. ***
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.
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!!
*** Bug 6144 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 6144 ***
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.