Closed
Bug 1507
Opened 26 years ago
Closed 26 years ago
Logging into any user auth protected realm causes Raptor to leak all resources and hang
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: angus, Assigned: morse)
References
()
Details
Here's how it used to work (A week or so ago):
I'd go to a site protected by user auth, where I have to enter a user/pass. For
example, the editors section of Mozilla.Org's Directory. In the MSDOS window,
I'd get the opportunity to type in my username and password, and upon
successfully doing so, the page would load and all would be well and good.
Now, here's what happens:
I load a URL that's protected by user auth, and my entire system seems to hang
(Win95) - I can move my mouse cursor, but that's it. Eventually (a few seconds),
things come back, and I can enter in a username/passwd in the MSDOS window, but
just as soon as I do that, everything seems to hang again.
Finally, I get an OS warning "Your system resources are dangerously low, would
you like to terminate this application (Raptor) not responding..." So I kill it.
I imagine this is related to our single sign on code, but I'm probably wrong...
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 2•26 years ago
|
||
Have extensively tested this and do not see either of the symptoms reported --
the response comes back right away and I do not get the memory-leak message. So
I'm closing this bug report as WORKS-FOR-ME and will reopen it if Angus can show
me the problem on his system.
The changes that I made last week that would affect this are the following:
1. I sound a bell when the authentication dialog is displayed on stdout. This
is to get the users attention since he would not normally be looking at stdout.
The use of the stdout for this dialog existed before I made any of my changes
and all I did was add the bell to alert the user.
2. The very first time the user submits any form containing a password (this is
such a case), I put up a message on stdout asking if the user wants
single-signon enabled. And I ring the bell as well.
I carefully code-reviewed both of these changes and don't see how either could
cause a performance hit or a memory leakage.
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.
reporter:
This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.
If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
but do not verify it yet.
For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.
You need to log in
before you can comment on or make changes to this bug.
Description
•