Closed Bug 21596 Opened 25 years ago Closed 25 years ago

browser content loading poisoned by open location & wallet master password dialog

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cpratt, Assigned: danm.moz)

References

(
URL
)

Details

(Whiteboard: [PDT+]RN) 

Build ID: 1999121308
Platform: Mac OS only. Fine on Win32 and Linux.

To reproduce:
- Launch mozilla
- Go to my.yahoo.com
- Log on using a Yahoo! ID and password
- Navigate through the Wallet dialogs (all 4 of them)

Result: The form is not submitted, and clicking on the Sign In button does not
do anything.

Expected result: The form should be submitted.
Is the form submitted properly if you single-signon pref is turned off (in that
case there will be no dialogs)?

This doesn't sound like a single-signon problem.  It's either a forms submit
problem (karnaze) or a dialogs problem (davidm) depending on the answer that I
get to the above question.
If you click Cancel at the first single signon dialog, the form is indeed
submitted properly.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Whiteboard: [PDT+]
This does appear to be a problem in single signon, but only happens the first
time you enable single-signon. If you shutdown, and restart, everything works
fine.

The symptom is actually that you seem to lose network connectivity. Not only
does the submit not happen, but you can't load any more web pages, either in the
current window, or in any other open windows.

Note: this happens at any site, not just my.yahoo.com.

Since there is an easy workaround (shutdown and re-start) this is not dogfood,
IMHO, so removing the PDT+ to send for re-evaluation.
Okay, let me say, that when I said it's a single-signon problem, I meant as
opposed to a form submission problem. I was considering the wallet dialogues a
part of single-signon.

Anyways, I can duplicate the symptoms by simply changing the wallet password in
Edit - Wallet - Change Password, so it appears to be a problem with the wallet
dialogues.

It looks like some kind of focus or event loop problem. Besides restarting, you
can also get around this bug by doing a File - New Navigator Window, which for
some reason kickstarts everybody back to life.

I'm cc:ing dougt, who apparently was working on some stuff that might be related
to this, per valeski.

This is definitely, definitely, a dialogue issue, as I have now reproduced the
same symptom using File - Open Web Location - which doesn't open the URL you
have given it until you open a new browser window.
Assignee: morse → davidm
It certainly is a dialog problem as opposed to a single-signon problem.
Assigning to davidm.
Assignee: davidm → danm
Pass on to danm since it sounds more like a dialog infrastructure rather than a
bug in my dialogs. I can't imagine what I would be doing that could cause you to
lose network connectivity.
Whiteboard: [PDT-]RN
Putting on the PDT- radar.  This only happens the first time you run.
Target Milestone: M14
targetting p3 for m14, a good workaround would be to get rid of the Wallet
dialogs that popup unbidden.
This same behaviour is also seen on the first Form Submission dialogue that
informs you about autofill. It is also seen the first time you save any new
signon, (which pretty much makes people want to turn off Single Signon).

I think this should be set to M13. If this bug was on Linux or Windows, people
would be screaming about it. cc:ing trudelle.

Still not PDT+, because people can turn off Single Signon as a decent
workaround, but I think the dialogue issue needs to be understood.
Summary: [PP][DOGFOOD]Mac OS -Form not submitted after Wallet dialogs → [PP][DOGFOOD]Form not submitted after Wallet dialogs
Dan still has far too many M13 bugs, I cannot add this one to them. We are
triaging bugs this week, and this one is quite doubtful for M14, especially
since Single Sign On is explicitly not required for beta 1. We should
consider disabling single sign on if this is a gating factor. We have too many
crucial problems in fundamental features to worry about, especially on Mac, to
bother with convenience add-ons like single sign on.
I just wish someone could at least take a look at this problem, because it is a
dialogue problem that just happens to manifest itself in wallet dialogues right
now. Who knows what other dialogues will have this problem!

In the current state of things we would definitely have to disable single-signon
and autofill at least on the Mac for Beta, without a doubt.
QA Contact: paulmac → sairuh
setting sairuh as QA contact for wallet bugs
The following seems to be the same problem: The pref "Prefill usernames and
passwords" is off.  Go to http://dmoz.org.  Click "Login".  I get the "Username
and Password" Prompt.  The window, however, is blank grey.  I close the window. 
Now I can't load any pages anymore, as paulmac described 12/13.

If I understand correctly, single signon is the feature that prefills username
and password in the password dialog for you.  I've had that turned off, and
still get the problem.  If this isn't fixed, you can't go to password
authenticated sites at all, and turning off single signon is not a workaround.
Keywords: pp
Yes, as I noted above, "it is a dialogue problem that just happens to manifest 
itself in wallet dialogues right now. Who knows what other dialogues will have 
this problem!"  Thus my concern about this bug.
*** Bug 23483 has been marked as a duplicate of this bug. ***
To reproduce this easily, 

1. Launch browser
2. Select File - Open Web Location and click in field and enter 
'www.mozilla.org' which will work fine.
3. Now repeat step 2, and enter a different URL if you would like.

Results: Page does not load until a new browser window is opened.
Changing summary line, lest anyone gets confused and still thinks that this is a 
wallet/single-signon problem.
Summary: [PP][DOGFOOD]Form not submitted after Wallet dialogs → [PP][DOGFOOD]Loss of network connectivity after using dialog
moving from leftover dogfood to beta1 radar
Keywords: beta1
Summary: [PP][DOGFOOD]Loss of network connectivity after using dialog → [PP]Loss of network connectivity after using dialog
Whiteboard: [PDT-]RN → RN
If your intent was to get this on the beta1 radar, you didn't do it right.  You 
removed the [dogfood] anotation but you need to add back a [beta1] anotation.  I 
just did that for you.
Summary: [PP]Loss of network connectivity after using dialog → [beta1] [PP]Loss of network connectivity after using dialog
Thanks Steve, but I did do it right, by adding 'beta1' to the keyword field.  
Removing extraneous [BETA1] from summary.
Summary: [beta1] [PP]Loss of network connectivity after using dialog → Loss of network connectivity after using dialog
Putting on PDT+ radar for beta1.
Whiteboard: RN → [PDT+]RN
*** Bug 25544 has been marked as a duplicate of this bug. ***
This bug has morphed into "Dialogs (including File | Open Location and htaccess
password dialogs) destroy network connectivity". This happens on Linux.  Does it
happen on Windows as well?  
Bug 25789 might be related: network connectivity loss after second IMAP/POP
password dialog.
25544 which has been marked and verified (by me) as a dulicate of this bug was 
reported as happening on Windows NT.  This would indicate that it is not Mac 
specific.
I can't reproduce this using the "Open Web Location" dialog anymore, because it
looks like you can't open any window twice anymore.

Also, I don't think network connectivity per se is broken.  If I reproduce the
sitation by attempting to load a page which is password protected, I can load
pages, although they are not displayed immediately.  If I click in the general
area where a scroll bar would be, the page appears.  Also, there are problems
with repainting the menus (click in menu bar, blank menu appears, options are
painted only once mouse enters menu area).

Bug 25710 (can't read imap mail) is probably the same phenomenon.  If it is,
then this problem now makes MailNews more or less unusable.

Changing platform/OS to all and remove pp keyword based on previous comments:
problem occurs on Win, Mac, and Linux.
Keywords: pp
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Please, do not morph bugs, close them and open new ones.
*** Bug 25677 has been marked as a duplicate of this bug. ***
Problem appears to be much more fundamental than network connectivity.  See bug 
25833.  I strongly suspect that these two bugs are dups except for one thing -- 
this bug has been around for a while and 25833 is a recent regression in the 
past few days.  So I won't mark it as a dup just yet.
Resolving bug 25833 has NOT also resolved this one.  I still see all the weird
behavior (menus not drawing, no effect when clicking on links, pages not drawing
until reload is pressed) after I get a wallet dialog for username/password.
In self defense, I am changing the COMPONENT field from single-signon to html 
dialogs (lest somebody should mistakenly decide to assign this bug to me).  As 
mentioned in this report, it is not a wallet or single-signon bug but rather a 
dialog bug.  Doing "open web location" demonstrates this bug as well.
Component: Single Signon → HTML Dialogs
After bug 25833 was fixed, I don't see this happening anymore with "Open Web
Location" and "Change Wallet Password".  On 2000.02.01.10 Linux build, only the
actual AutoFill Password dialog breaks things.
QA Contact: sairuh → elig
dialog issue? this is one's for eli. :-)
Bug 26712 might be a duplicate of this.  Reporter submitted a testcase there.
Blocks: 26981
Changing component to XP Apps. (HTML Dialogs is going away.)
Component: HTML Dialogs → XPApps
  What has this bug morphed into lately? I notice test cases in other bugs which 
are marked "works for me." Today I'm seeing no problems on Linux or NT, but on 
the Mac, I'm seeing my.yahoo.com and a simple htaccess-protected page both 
failing to load anything after the wallet master password dialog has come up. 
That window will load nothing from the network or a local file until you open 
another, different browser window. Then it comes back to life. But note that 
other dialogs, including cookie warnings and the auth dialog itself, don't have 
this effect.
  ...fighting the temptation to reassign to morse, just because he's been so 
fastidious in asserting that this bug isn't his...
  I'm changing the summary and platform fields to reflect what I'm seeing. Please 
correct me if you, kind reader, can still see a more widespread problem with 
today's build.
Status: NEW → ASSIGNED
OS: All → Mac System 9.0
Hardware: All → Macintosh
Summary: Loss of network connectivity after using dialog → browser content loading poisoned by wallet master password dialog
Sorry, I didn't mean to be fastidious in asserting that this bug isn't mine.  
It's just that some of the other comments in the bug report suggested a 
more-general problem to me.

Since it has morphed so much, I no longer know what is working and what isn't.  
Dan, does it still occur after "open web location" on the mac?
Oops. Heh. I hadn't even tried Open Web Location, since it had been reported as 
working. Doesn't work for me.
Summary: browser content loading poisoned by wallet master password dialog → browser content loading poisoned by open location & wallet master password dialog
Yet another way to get this behavior is to put in a bad url such as 
http://www.blahblahblahblah.com and get a 'URL could not be found' dialogue. The 
second time you get one of this, you won't be able to load a new url until you 
open a new navigator window. This is assuming you have keywords turned off (if 
you have keywords turned on, you are directed to keyword.netscape.com instead of 
getting the error dialog).
OK, I've found a Mac-specific problem: an exiting modal event loop would 
prematurely destroy the Mac event loop repeater. Bug is fixed on the Mac. I've 
been unable to reproduce the problem on other platforms and no one has objected 
to my making it a Mac-only bug, so I'm calling it fixed. Hoo boy.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
<Will verify when we get a working Mac build...>

*** Bug 27715 has been marked as a duplicate of this bug. ***
Ouch. I'd like to verify this bug thoroughly, but I'm sure sure where to start.

Paulmac & cpratt (using my.netscape --- don't have yahoo account)'s examples both 
work fine on the 2.14.00 Mac OS build. Would anyone else like to suggest 
additional snippets from this bug that are still relevant to check?

Thanks!

I don't see this happening anymore on Linux build 2000.02.14.09.  All the
scenarios that made this happen for me in the past now work fine (testcase in
bug 26712, htaccess dialog, MailNews password dialogs, network alerts).

I agree with zach, this is definitely fixed - i tried all the different 
dialogues I could think of. marking verified with 2/15 builds on mac

at last! :-)
Status: RESOLVED → VERIFIED
OS: Mac System 9.x
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.