Steps to reproduce problem: 1. Accidentally launch firefox -no-remote when it is already running 2. Notice that the profile unlocker now offers to kill the existing process 3. Press Escape assuming it will have the same effect as Cancel Actual result: Existing Firefox process is killed Expected result: Profile unlock dialog is cancelled

I agree this is probably correct, but I'd like to get the UX decision as part of bug 1057052.

Comment on attachment 8481365 [details] [diff] [review] Proposed patch Can you attach a screenshot of what this looks like on windows now? If I'm reading this right, you're changing the button ordering, and removing BUTTON_POS_1_DEFAULT, and I'm not sure how this affects the appearance and the default button styling (if there is a default button now that is activated with enter?)

(In reply to Benjamin Smedberg from comment #3) > Can you attach a screenshot of what this looks like on windows now? I'll get you one tomorrow, I only have Windows 2003 right now. > If I'm reading this right, you're changing the button ordering, and > removing BUTTON_POS_1_DEFAULT, and I'm not sure how this affects the > appearance and the default button styling (if there is a default button > now that is activated with enter?) The default default button is button 0. This is now the button labelled "Close %S". Button 1 is now labelled "Cancel". Pressing Escape is always equivalent to button 1.

Whoops, I wasn't thinking straight, and unticked the checkbox to clear the needinfo request...