Closed
Bug 13032
Opened 25 years ago
Closed 25 years ago
Autofill dialogs should be Yes/No, not Ok/Cancel
Categories
(SeaMonkey :: UI Design, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: mscott, Assigned: don)
References
Details
David,
I'm seeing something very similar to Bug #11470 again. I have some code in my
tree which uses Steve's wallet code to store and prompt the user for their imap
password. This snippet of code is not checked into the tree. I can send you the
file if you need it.
Basically, the wallet supports nsIPrompt interface too. I'm calling
PromptPassword on Steve's code which turns around and calls your code to bring
up a password dialog prompt.
For imap, when the prompt comes up, the window is empty (it basically captures
whatever was underneath the window before it was created).
Sorry for the vague problem description. The symptoms are just like 11470 except
this time, the imap stuff is calling wallet and wallet is calling you.
Reporter | ||
Updated•25 years ago
|
Assignee: davidm → morse
Reporter | ||
Comment 1•25 years ago
|
||
David, I'm sorry. I'm smoking something today. The password dialog comes up
fine. The problem is with the wallet dialog that comes up after accepting the
password asking me if I want it remembered.
I'm going to re-assign to Steve but keep you on the cc list because whatever you
did to fix 11470 is probably what Steve needs for this prompt dialog that he's
bringing up too.
Reporter | ||
Comment 2•25 years ago
|
||
Here's what on the stack when the dialog comes up blank. I broke into the
debugger to get this. This may be David's afterall.
nsAppShell::GetNativeEvent(nsAppShell * const 0x042caa90, int & 1, void * &
0x015f6d68 msg) line 124 + 17 bytes
nsWebShellWindow::ShowModalInternal(nsWebShellWindow * const 0x043321e0) line
1777 + 20 bytes
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x043321e0) line 1749 + 9
bytes
nsAppShellService::RunModalDialog(nsAppShellService * const 0x00ece310,
nsIWebShellWindow * * 0x0012fa7c, nsIWebShellWindow * 0x00000000, nsIURI *
0x04335f00, unsigned int 1073743870, nsIXULWindowCallbacks * 0x042b4904, int
300, int 200) line 669
nsNetSupportDialog::DoDialog(nsString &
{"chrome://navigator/content/NetSupportConfirmYN.xul"}) line 679
nsNetSupportDialog::ConfirmYN(nsNetSupportDialog * const 0x042b4900, const
unsigned short * 0x04337030, int * 0x0012fb4c) line 455
Wallet_ConfirmYN(char * 0x04335680) line 783 + 26 bytes
si_ConfirmYN(char * 0x04335680) line 106 + 9 bytes
si_OkToSave(char * 0x042b4680, char * 0x042b45c0) line 2014 + 9 bytes
SINGSIGN_PromptPassword(const unsigned short * 0x042b49f0, unsigned short * *
0x0012fd4c, int * 0x0012fd50, const char * 0x042b4b90) line 2439 + 35 bytes
nsWalletlibService::PromptPassword(nsWalletlibService * const 0x02671600, const
unsigned short * 0x042b49f0, unsigned short * * 0x0012fd4c, int * 0x0012fd50,
const char * 0x042b4b90) line 135 + 21 bytes
Updated•25 years ago
|
Assignee: morse → davidm
Comment 3•25 years ago
|
||
I hadn't seen 11470 before but it sounds like it was the same bug as 12137 that
I was tracking and that suddenly started working about a week ago. But I
discovered that the problem was not completely fixed and so I filed bug report
12728 just this week. Sounds like 12728 is a dup of this 13032 bug. Take a
look there since I have more info about the problem in that report.
So, I agree, this is definitely David's. Reassigning back to him
Heres the problem. The YN code is using the old nsNetSupportDialog code which
has more problems than you can shake a stick at. If you try a standard confirm I
would expect it to work since I am proxying those calls over to the new dialog
code.
Comment 5•25 years ago
|
||
Why are these different? When I added the YN dialogs, they were made identical
to the standard confirm dialogs except for the labelling on the buttons. So I
presume that you have now changed the way you handle the standard dialogs but
did not make that same change to the YN dialogs. Could you make that same
change to the YN dialogs?
Comment 7•25 years ago
|
||
David's suggested work-around works -- namely using the standard dialogs
(OK/Cancel) instead of the yn (yes/no) ones. So I have temporarily
checked-in modified wallet/single-signon code that uses the ok/cancel dialog
instead. Once this bug is fixed, I can revert back to the yes/no dialog. Same
comment applies to cookie nag box (bug 12728) which was also affected by this
bug.
Note: now that I have made these changes, it is no longer possible to
demonstrate either this bug or bug 12728. But I made the changes under an
#ifdef YN_DIALOGS_FIXED. So to once again demonstrate these bugs, add the
following line to both nsCookie.cpp (extensions/cookie) and wallet.cpp
(extensions/wallet/src):
#define YN_DIALOGS_FIXED 1
Reporter | ||
Comment 8•25 years ago
|
||
Thanks Steve, I've verified that the dialog comes up correctly for me now after
you switched to the Y/N prompt.
Comment 9•25 years ago
|
||
You mean "switched to the OK/Cancel prompts" of course.
Component: XP Toolkit/Widgets → XPApps
Priority: P3 → P2
Target Milestone: M14
Assignee | ||
Comment 10•25 years ago
|
||
We can fix this after beta.
Comment 11•25 years ago
|
||
*** Bug 15406 has been marked as a duplicate of this bug. ***
Comment 12•25 years ago
|
||
*** Bug 19100 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Summary: problem bringing up password dialog through wallet code → Autofill dialogs should be Yes/No, not Ok/Cancel
Comment 13•25 years ago
|
||
I've amended the subject to that of bug #15406, as it's my understanding that
this bug is now being used to track the need to change the OK/Cancel dialogs to
Yes/No dialogs, per davidm's resolution of bug #19100 as a duplicate of this one.
Please undo this change if I'm mistaken.
Comment 14•25 years ago
|
||
*** Bug 19935 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
QA Contact: phillip → paulmac
Comment 15•25 years ago
|
||
*** Bug 22280 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
This bug sure keeps getting reported over and over again (see all the dups).
I'd like to make a plea to get this done in M13 instead of M14 as it is
currently marked.
Comment 17•25 years ago
|
||
*** Bug 22418 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
*** Bug 22335 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•25 years ago
|
||
M15.
Comment 20•25 years ago
|
||
*** Bug 22845 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 21•25 years ago
|
||
I implemented a universal dialog from which I can custom-build various dialogs.
The Yes,No dialog requested here is a special case of the universal dialog.
It's now checked in and working. Marking bug as fixed.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 22•25 years ago
|
||
verified 1/6
Comment 23•25 years ago
|
||
*** Bug 23710 has been marked as a duplicate of this bug. ***
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
•