Bugzilla

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended (by adding more instances of that), but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. That's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go the call stack back, for all callers - there may be several scenarios.

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended, by adding more instances of that, but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. That's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go back the call stack, for all possible callers - there may be several scenarios.

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended (by adding more instances of that), but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. That's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go back the call stack, for all possible callers - there may be several scenarios.

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended (by adding more instances of that), but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. I agree, that's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go back the call stack, for all possible callers - there may be several scenarios.

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended (by adding more instances of that), but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. I agree, that's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go back the call stack, for all possible callers - there may be several scenarios. If you can show what this does in *all* the different cases, and that is the right thing in every case, I'd be happy to revert my r- into a r+ for that patch.

> if a filter action that, say, moves a message from an authenticated to an unauthenticated account occurs after biff brings in new messages on the authenticated account, a password dialog pops up for the currently unauthenticated account

As I've mentioned, it's very possible that there are bugs in the existing code that violate the assumptions and expected behavior. These are bugs and should not be extended (by adding more instances of that), but fixed.

Comment 23 explains in detail how and why that matters to end users.

> alert messages like "you've got new mail" or "can't connect to mail server" pop up at any time but go away on their own and generally require no user interaction.

You mean the Windows/Linux/Mac notifications, not popup windows within Thunderbird, right? That's fine, because they are intended for background notifications, i.e. actions that the application initiated and not the end user. I agree, that's an appropriate place to show such errors.

As far as I remember, `AlertUserEventUsingName()` is not the same as these OS notifications, but IIRC can get converted back into an error for the caller. That may or may not do what we want here. You'd need to go back the call stack, for all possible callers - there are several scenarios. If you can show what this does in *all* the different cases, and that is the right thing in every case, I'd be happy to revert my r- into a r+ for that patch.