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].
+++ 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].

Back to Bug 1720214 Comment 0