Well that's effectively what we call 'modal' except for that you could filter WM_PAINT or its non-Win32 counterparts easily. But still, not an ideal solution.
I don't see the real problem. At some point in the security core there's going to be a call to the central password storage, and how hard can it be to put a simple mutex there before opening it so no separate threads can access it simultaneously, thus automatically avoiding simultaneous dialogs on the subject with a few simple lines of code? Release the mutex after either granting or denying access, and there you go.
Only negative side effect would be that in the case of reopening 3 password protected tabs *without wanting to open them*, for example if you have a non-trusted visitor next to your keyboard, you'd have to decline entering the password 3 times. Well, in that case you choose to deny opening 3 password protected tabs explicitly, so that's acceptable I think.
Well that's effectively what we call 'modal' except for that you could filter WM_PAINT or its non-Win32 counterparts easily. But still, not an ideal solution.
I don't see the real problem. At some point in the security core there's going to be a call to the central password storage, and how hard can it be to put a simple mutex there before opening it so no separate threads can access it simultaneously, thus automatically avoiding simultaneous dialogs on the subject with a few simple lines of code? Release the mutex after either granting or denying access, and there you go.
Only negative side effect would be that in the case of reopening 3 password protected tabs *without wanting to open them*, for example if you have a non-trusted visitor next to your keyboard, you'd have to decline entering the password 3 times. Well, in that case you choose to deny opening 3 password protected tabs explicitly, so that's acceptable I think.