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)

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: 25 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.