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)

PowerPC
Mac System 9.x

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: danm.moz)

References

()

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.