1888100 - Confirmation message should be removed after a certain period of time.

Status: NEW

(Firefox :: Shell Integration, enhancement)

Description

[Monica Chiorean]

Found in

• version: 125.0b1

Affected versions

• version1: 125.0b1

Tested platforms

• Affected platforms: Windows only
• Unaffected platforms: Ubuntu, Mac

Preconditions

• Have a Firefox build installed.
• Use a clean profile
• Use these credentials for Sogo (user: sogo1, pass: sogo)
• Set the pref "browser.mailto.dualPrompt" to "true"
• Have Mail/Chrome set as default mailto application at OS level

Steps to reproduce

1. Visit https://demo.sogo.nu/SOGo/ and login with a valid account (see preconditions).
2. Click the "Set as default" button from mailto prompt.
3. Check the confirmation message.
4. Wait for the confirmation message to disappear.

Expected result

• Confirmation message should be removed after a certain period of time.

Actual result

• Confirmation message is not removed, unless the page is refreshed or changed.

Regression range

• Not a regression as this is new implementation.

Notes: Please take into consideration that this is an enhancement, that I think users will appreciate. Thank you.

Comment 1

[Max]

I noticed during the implementation that we have not defined a timeout length and asked the UX team about it. Out came an answer from the accessibility team (thanks Anna Yeddi), that timeouts can be problematic for some users and should be carefully considered after a w3 rfc.

So I followed the advise from Josh Berman and removed the timeout code entirely. Because of that I am in the belief that we can close this bug as WONTFIX, because it would only cause problems for some users and with little benefit to others, because the confirmation appears so rarely.

Do you agree, David?

Comment 2

[Anna Yeddi [:ayeddi]]

(In reply to Max from comment #1)

I noticed during the implementation that we have not defined a timeout length and asked the UX team about it. Out came an answer from the accessibility team (thanks Anna Yeddi), that timeouts can be problematic for some users and should be carefully considered after a w3 rfc.

So I followed the advise from Josh Berman and removed the timeout code entirely. Because of that I am in the belief that we can close this bug as WONTFIX, because it would only cause problems for some users and with little benefit to others, because the confirmation appears so rarely.

Do you agree, David?

Thank you for including the accessibility consideration!

If we need to have some form for a notification dismissal that is not clicking the X Close button, we could also implement some form of user interaction-based trigger to dismiss it, for instance, when/if a user clicks something on the web content backed up by user pressing Escape anywhere or/and by user pressing Enter/Space on a control elsewhere - this may be considered as an identification that the user has reviewed the notification and wants to proceed further. Escape key is expected to dismiss dialogs, but listening to clicks or Enters is not similar indication though, because a user may not even notice the notification being added to the screen (i.e. when they're using a magnifier and reviewing other part of the screen) or the click/enter may be accidental (i.e. when a blind keyboard-only user shares a desktop with a mouse user, they may accidentally touch this mouse and send a click). But this is the gray area that could be considered and, AFAIK, it is or planning to be used elsewhere for status notifications.