+++ This bug was initially created as a clone of Bug #1342809 +++ There are several things which are wrong and odd about the new helpful alert when replying to no-reply addresses, introduced in bug 1342809. STR - Reply to a message from "noreply@example.com", which will trigger the `Reply not Supported` alert. - When the alert is showing: - Click `Cancel` button (and compare its position with other dialogs) - Press `Escape` on keyboard - Click [x] in alert corner Actual results: - `Cancel` button is on the left, violating mouse muscle memory (for Windows at least), because all `Cancel` buttons are on the right (plus we don't have a choice if we want to fix the behaviour, see below). - `Escape` triggers `Reply Anyway`, making the alert a no-op for keyboard users, and very confusing. - Clicking `[x]` to close the alert without action also triggers `Reply Anyway`. - The wording is odd, as Henry already mentioned: What is a `monitored address`? Never heard of that, hard to translate, but if anything, it sounds like espionage... let's try to keep it simple, please... Expected results: - `Cancel` button should be in default position on the right. - `Escape` and [x] must trigger the same action as `Cancel`. - Improve the wording and avoid the term `monitored address`. The confirmEx() alert misbehaviour is bug 345067 (which sucks), but we can easily work around that by reversing the button sequence so that `Cancel` button will be in position 1 and return 1, consistent with `Escape` and [x].
Bug 1720214 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
+++ This bug was initially created as a clone of Bug #1342809 +++ There are several things which are wrong and odd about the new helpful alert when replying to no-reply addresses, introduced in bug 1342809. STR - Reply to a message from "noreply@example.com", which will trigger the `Reply not Supported` alert. - When the alert is showing: - Click `Cancel` button (and compare its position with other dialogs) - Press `Escape` on keyboard - Click [x] in alert corner Actual results: - `Cancel` button is on the left, violating mouse muscle memory (for Windows at least), because all `Cancel` buttons are on the right (plus we don't have a choice if we want to fix the behaviour, see below). - `Escape` triggers `Reply Anyway`, making the alert a no-op for keyboard users, and very confusing. - Clicking `[x]` to close the alert without action also triggers `Reply Anyway`. - The wording is odd, as Henry already mentioned: What is a *monitored address*? Never heard of that, hard to translate, but if anything, it sounds like espionage... let's try to keep it simple, please... Expected results: - `Cancel` button should be in default position on the right. - `Escape` and [x] must trigger the same action as `Cancel`. - Improve the wording and avoid the term `monitored address`. The confirmEx() alert misbehaviour is bug 345067 (which sucks), but we can easily work around that by reversing the button sequence so that `Cancel` button will be in position 1 and return 1, consistent with `Escape` and [x].
+++ This bug was initially created as a clone of Bug #1342809 +++ There are several things which are wrong and odd about the new helpful alert when replying to no-reply addresses, introduced in bug 1342809. STR - Reply to a message from "noreply@example.com", which will trigger the `Reply not Supported` alert. - When the alert is showing: - Click `Cancel` button (and compare its position with other dialogs) - Press `Escape` on keyboard - Click [x] in alert corner Actual results: - `Cancel` button is on the left, violating mouse muscle memory (for Windows at least), because all `Cancel` buttons are on the right (plus we don't have a choice if we want to fix the behaviour, see below). - `Escape` triggers `Reply Anyway`, making the alert a no-op for keyboard users, and very confusing. - Clicking `[x]` to close the alert without action also triggers `Reply Anyway`. - The wording is odd, as Henry already mentioned: What is a *monitored address*? Never heard of that, hard to translate, but if anything, it sounds like espionage... let's try to keep it simple, please... Expected results: - `Cancel` button should be in default position on the right. - `Escape` and [x] must trigger the same action as `Cancel`. - Improve the wording and avoid the term `monitored address`. The `confirmEx()` alert misbehaviour is bug 345067 (which sucks), but we can easily work around that by reversing the button sequence so that `Cancel` button will be in position 1 and return 1, consistent with `Escape` and [x].