When you enter a form with a user/pass (for example, chat.yahoo.com), the query as to whether you want "The browser to remember you username and password..." appears in the stdout, not a dialog box. Meanwhile, the UI is frozen along with (almost) everything else. Most users won't know to look in the stdout. Can we disable this until we can show this query in dialog boxes?

This also occurs when logging into Netcenter. While the system is waiting for the user to type something into stdout, the UI for viewer is totally locked (doesn't repaint) and the user can't do anything. Most people will think the browser crashed. This is unnacceptable - we need to disable the user/pass caching stuff until it can use a dialog box or some other realistic UI. Upping priority, severity; setting "ss" in summary. Gagan - this only started happening this week.

Looks like this might be related to Steve Morse's recent work. To Steve for comments...

Yes, this is from single signon. The problem is that the infastructure for displaying a dialog box (FE_Confirm) is not yet in place. So I added a temporary FE_Confirm which displays the message in stdout. Furthermnore, it sounds a bell to alert the user to this message. So rather than suppressing SingleSingon, I'd rather assign this bug to whomever it is that is implenting the raptor equivalent of FE_Select. Can someone tell me who that it? If it is deemed desirable, we could disable this by removing the -DSingleSignon from config.mak. But in my opinion that would be a bad thing to do for all of the following reasons: 1. We want to get as much use out of single signon as possible so we can shake out the bugs. 2. The people who are currently using the browser are not novice users but, on the contrary, are developers and as such they can easily live with dialog boxes coming up in stdout for the time being. 3. Disabling the feature would take the pressure off the appropriate people to implement the raptor-based FE_Select (or its equivalent). This is a critical dependency and we should put pressure on getting that in place ASAP.

As much as I agree with morse, I am getting inclined towards suggesting that we should leave SingleSignon for Dec. release. Today is supposed to be a code freeze for the same and we don't know who is responsible for FE_Select. So I would recommend that SingleSignon's switch be flipped for now (build it only when its defined as an environment variable) Once the dec/dev release rolls out we can get this back on a higher priority. Steve could you kindly do this?

The problem is not just single signon. As pointed out in e-mail messages, this problem already existed for any site that requires authorization. Such authorization dialog comes up in the stdout window and this occurred before I ever added single signon. All I did was use the same temporary UI for the single singon dialog that the authorization code was already using. So unless we are going to remove this from all pages requesting authorization, I don't see a compelling reason for removing it just for single singon. I agree with Angus's comment that we can handle this by desribing it in the release notes.

Please leave this on ss: so QA can Verify that this is out temporarily on next build. morse - per bug mtg today, please pull this festure for now. Thanks!

I would probably agree with morse if it weren't for the performance problems we're experiencing (see bug 1507). Let's turn this off for now please. The issue of getting the FE stuff implemented is not low on anyone's radar - it's a top priority not only for this sort of thing, but for simple stuff like JavaScript alerts. Finally, while I think you're right about how the usability problem is there even without Single Sign on code for things like user_auth, the problem is that the signle sign on code introduces this problem for a far greater number of scenarios, such as any HTML form with a password field. Please let's turn this off just for a few days.

There are several points in Angus's comments above that I need to reply to. 1. Angus mentioned the problem re bug 1507. That bug report talks about a memory leak. I have looked into that bug and have not been able to reproduce such a leak. 2. The code executed in bug 1507 has little to do with single signon -- it involves the authentication dialog which already existed prior to single signon being introduced. So whatever performance problem exists (and I agree there is a performance problem there), removing single signon will not change that -- the performance will be the same. 3. It's incorrect to say that single signon introduces the problem to a far greater number of scenarious than does the authentication dialog. Yes, single signon occurs on every page with a password form. But authentication occurs on every page that requires authentication. Furthermore, when the single-signon dialog occurs for the first time, the user is asked if he wants to have the feature enabled and if he says no he never gets a single-signon dialog again, either in the current session or in any subsequent ones. The authentication dialog, on the other hand, occurs over and over again every time the user accesses a page that needs authentication.

Two quick comments -- "It's incorrect to say that single signon introduces the problem to a far greater number of scenarious than does the authentication dialog. Yes, single signon occurs on every page with a password form. But authentication occurs on every page that requires authentication." -- Actually, the former is far greater than the latter, so the user *does* run into this problem on a far greater number of sites (logging into netcenter, for instance) Secondly, while I want to believe the claim that the performance degredation (bug 1507) is not the single sign on code, the fact remains that I use the viewer to access those sorts of sites and I never experienced the performance slow down until the single sign on code was checked in. If you feel passionately about this, leave it it. But I am fundamentally convinced that it's the wrong thing for the product at this stage, and that we'll confuse a lot of users.

Angus, You missed the point of my comment about single signon being encountered less frequently than authentication. There is an initial single-signon message will happen exactly once and never again for the life of the browser. No further single-signon messages occur unless the user responds to that message by saying that he wants to enable single signon. The authentication message will keep occuring every time the user goes to a site that requires authentication. I agree with you that the one time that this message occurs will confuse lots of users. But the many times the authentication message occur will confuse them much more. I will immediately look into the degredation issue some more (bug 1507) to determine that either it is not single-signon related or, if it is, then to fix it.

You're right - I'm wrong -- I missed that point. Let's release note it assuming 1507 is not SSI related. If 1507 isn't SSI, let's reassign it back to gagan. Sorry for my confusion.

Putting on ss:rn radar.

I have thouroughly tested 1507 and do not see any poor performance. Nor do I see the memory leak reported there. I don't know why Angus is seeing a degredation and perhaps I'll take a look at his system when I'm down at Netscape this Wednesday. See my additional comments in bug report 1507 OK, I know what the cause of the degradation is in bug 1507. It's not single-signon related but it does have to do with some other changes I made at the same time that I added single signon. See bug report 1507 for details.

oops -- ignore last paragraph in comment above. That was temporary wording that I meant to delete before submitting but apparently I forgot to do so. The first paragraph is the comment I meant to make.

I do not understand why this is still being discussed. My reading of the bug is that it was decided at yesterday's bug meeting that this should be turned off (see Leger comment above). Despite the more recent Angus/Morse comments, it seems that this decision still applies. Steve, could you turn the feature off for now (as per Gagan and Leger's comments), or discuss at today's bug meeting?

Per leger/rickg discussion, I will Release Note this behavior.

ok, my confusion. Thanks for updating the bug, Leger.

Decided not to Release Note this. Pulling off rn: status.

Why did we decide not to release note this? This should be in the release notes.

Contradictory to Jan's comment above, this was indeed released-noted. To wit: Dialogs like JavaScript alert, confirm, and prompts, as well as other dialogs such as user authentication, cookie warnings, form submission warnings, DNS lookup failed, etc. are not currently enabled in NGT. In place of many of these dialogs, text is printed to the console window instead.

Yep. I did put it in and forgot to update bug. My apologies.

This is not a bug. It reflects the state of the browser in the sense that the infastructure for displaying dialogs has not yet been implemented. That's different than saying that the UI for single-signon (user/password) is confusing. So I am closing this report as being invalid.

Verifying as Invalid

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.