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)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
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.
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [PDT+]
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: morse → davidm
Comment 6•25 years ago
|
||
It certainly is a dialog problem as opposed to a single-signon problem.
Assigning to davidm.
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.
Updated•25 years ago
|
Target Milestone: M14
Comment 9•25 years ago
|
||
targetting p3 for m14, a good workaround would be to get rid of the Wallet
dialogs that popup unbidden.
Comment 10•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: [PP][DOGFOOD]Mac OS -Form not submitted after Wallet dialogs → [PP][DOGFOOD]Form not submitted after Wallet dialogs
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: paulmac → sairuh
Comment 13•25 years ago
|
||
setting sairuh as QA contact for wallet bugs
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
*** Bug 23483 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
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
Comment 19•25 years ago
|
||
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
Comment 20•25 years ago
|
||
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
Comment 21•25 years ago
|
||
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
Comment 23•25 years ago
|
||
*** Bug 25544 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
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?
Comment 25•25 years ago
|
||
Bug 25789 might be related: network connectivity loss after second IMAP/POP
password dialog.
Comment 26•25 years ago
|
||
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.
Comment 27•25 years ago
|
||
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.
Comment 28•25 years ago
|
||
Please, do not morph bugs, close them and open new ones.
Comment 29•25 years ago
|
||
*** Bug 25677 has been marked as a duplicate of this bug. ***
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
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.
Comment 32•25 years ago
|
||
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
Comment 33•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: sairuh → elig
Comment 34•25 years ago
|
||
dialog issue? this is one's for eli. :-)
Comment 35•25 years ago
|
||
Bug 26712 might be a duplicate of this. Reporter submitted a testcase there.
Comment 36•25 years ago
|
||
Changing component to XP Apps. (HTML Dialogs is going away.)
Component: HTML Dialogs → XPApps
Assignee | ||
Comment 37•25 years ago
|
||
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
Comment 38•25 years ago
|
||
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?
Assignee | ||
Comment 39•25 years ago
|
||
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
Comment 40•25 years ago
|
||
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).
Assignee | ||
Comment 41•25 years ago
|
||
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
Comment 42•25 years ago
|
||
<Will verify when we get a working Mac build...>
Comment 43•25 years ago
|
||
*** Bug 27715 has been marked as a duplicate of this bug. ***
Comment 44•25 years ago
|
||
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!
Comment 45•25 years ago
|
||
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).
Comment 46•25 years ago
|
||
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
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
•