Closed Bug 13032 Opened 20 years ago Closed 20 years ago

Autofill dialogs should be Yes/No, not Ok/Cancel

Categories

(SeaMonkey :: UI Design, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

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.
Assignee: davidm → morse
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.
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
Assignee: morse → davidm
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.
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?
*** Bug 12728 has been marked as a duplicate of this bug. ***
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
Thanks Steve, I've verified that the dialog comes up correctly for me now after
you switched to the Y/N prompt.
You mean "switched to the OK/Cancel prompts" of course.
Component: XP Toolkit/Widgets → XPApps
Priority: P3 → P2
Target Milestone: M14
We can fix this after beta.
*** Bug 15406 has been marked as a duplicate of this bug. ***
*** Bug 19100 has been marked as a duplicate of this bug. ***
Summary: problem bringing up password dialog through wallet code → Autofill dialogs should be Yes/No, not Ok/Cancel
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.
*** Bug 19935 has been marked as a duplicate of this bug. ***
QA Contact: phillip → paulmac
*** Bug 22280 has been marked as a duplicate of this bug. ***
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.
*** Bug 22418 has been marked as a duplicate of this bug. ***
*** Bug 22335 has been marked as a duplicate of this bug. ***
Assignee: davidm → don
Target Milestone: M14 → M15
M15.
*** Bug 22845 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
verified 1/6
*** Bug 23710 has been marked as a duplicate of this bug. ***
Target Milestone: M15 → M13
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.