Closed
Bug 3684
Opened 26 years ago
Closed 25 years ago
Viewing a page that requires a password gives bad UI
Categories
(SeaMonkey :: UI Design, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M6
People
(Reporter: cpratt, Assigned: davidm)
References
()
Details
If you visit the above URL, the browser will draw what appears to be a password
entry dialog box over the regular browser window. Neither that window nor the
original browser window are then refreshed, and you can't enter a user name or
password either there, or in the DOS window. Happens with apprunner, 12 March
build. Additionally, clicking on either window's Close box closes all windows
and quits apprunner.
Assignee: don → davidm
Summary: Viewing a page that requires a password gives bad UI → Viewing a page that requires a password gives bad UI
Target Milestone: M3
Re-assigned to davidm@netscape.com, changed component to XPApps and target
milestone to M3.
David, this will be fixed by the client auth stuff you, rpotts, and spence are
working on, right?
Updated•26 years ago
|
QA Contact: 3849 → 4137
Comment 3•26 years ago
|
||
assigning Christopher as QA contact
Changed target milestone to M4.
Move this to M4 until we know spence has delivered the netlib changes.
*** Bug 4136 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Target Milestone: M4 → M5
Comment 7•26 years ago
|
||
not going to make m4. moving to m5.
*** Bug 3685 has been marked as a duplicate of this bug. ***
*** Bug 3781 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 10•25 years ago
|
||
*** Bug 3686 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
David still has to hack around netlib for this to work in Windows and Linux.
We're not going to solve this for M5. Moving to M6.
Assignee | ||
Comment 12•25 years ago
|
||
Just to be clear the problem is that not so much in netlib as in our cross thread
communications method (PLEvents). You can't block when handling the PLEvent which
tells you to bring up the window since netlib is going to be sending a bunch of
important events which you don't want queueing up behind your event. My current
plan to from the PLEvent to spin off a timerevent and have the timer event
actually put up the dialog. Not exactly elegant and perhaps someone should
investigate better ways of doing cross thread communications.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•25 years ago
|
||
fix checked in. Tested on win,linux and mac by loggin on to parp.
Reporter | ||
Comment 14•25 years ago
|
||
although I can ping parp.mcom.com, I can't get apprunner to connect to it. what
am I doing wrong? thanks!
Assignee | ||
Comment 15•25 years ago
|
||
I think Parp is down. Feel free to use any other site. I just had a know password
for that site.
Status: RESOLVED → VERIFIED
Whiteboard: apprunner can't / won't connect to parp.mcom.com
Reporter | ||
Comment 16•25 years ago
|
||
hm. well, it mostly works save for cosmetic issues. i'm going to mark this one
as verified fixed & open new ones for any remaining issues.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•