1331924 - "Page Bookmarked" panel won't disappear

Status: RESOLVED INCOMPLETE

(Firefox :: Bookmarks & History, defect, P3)

Description

[atlanto]

STR:
1. Click the star icon
2. Move mouse pointer inside the "Page Bookmarked" panel
3. Move mouse pointer outside the panel quickly or very quickly or extremely quickly
4. Wait the panel auto-closing
AR:
The panel stays forever.
ER:
The panel closed.
(Oh, I don't expect/hope/wish/require/need the editable panel auto-closed. :( )

This occurs on Windows10 and Linux(mint,manjaro).
If you move mouse slowly, the panel will vanish of course. Auto-closing or whatever must not depends on mouse speed.

Comment 1

[Marco Bonardo [:mak]]

In the past I have noticed some mouseout events not firing for very quick movements, that may be the case here.

Comment 2

[Anna Yeddi [:ayeddi]]

This issue is still present on Windows 11 with Firefox Nightly 115 and it does happen when no mouse events is produced. This would affect accessibility of the panel and would be failing WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable - the panel remains opened for about 5 seconds only, while it is expected to allow users to have at least 20 seconds to perform one action (i.e. do one Tab key press for a keyboard-only or a switch device user). A user of a screen reader with slower screen reader speech settings would only hear that the panel is opened and the panel would collapse even before they may realize that there was, in fact, an option to customize the bookmark.

This insufficient timeout would make the feature not discoverable/actionable for users with lower mobility, with cognitive difficulties, and users with low vision and blind users, thus setting the accessibility severity to [access-S2]

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:mak, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Anna Yeddi [:ayeddi] from comment #2)

This issue is still present on Windows 11 with Firefox Nightly 115 and it does happen when no mouse events is produced. This would affect accessibility of the panel and would be failing WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable - the panel remains opened for about 5 seconds only, while it is expected to allow users to have at least 20 seconds to perform one action (i.e. do one Tab key press for a keyboard-only or a switch device user).

This bug is about the opposite, the user was reporting the panel remained open instead of being closed automatically.
I think you meant to comment in Bug 1809747? That bug is actually marks as access: S3, should it be changed?

I'm unsure about the fate of this 7 years old bug, it may be closed as worksforme or incomplete since there's no steps we can use to reproduce the bug easily.

Comment 5

[Anna Yeddi [:ayeddi]]

(In reply to Marco Bonardo [:mak] from comment #4)

(In reply to Anna Yeddi [:ayeddi] from comment #2)

This issue is still present on Windows 11 with Firefox Nightly 115 and it does happen when no mouse events is produced. This would affect accessibility of the panel and would be failing WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable - the panel remains opened for about 5 seconds only, while it is expected to allow users to have at least 20 seconds to perform one action (i.e. do one Tab key press for a keyboard-only or a switch device user).

This bug is about the opposite, the user was reporting the panel remained open instead of being closed automatically.
I think you meant to comment in Bug 1809747? That bug is actually marks as access: S3, should it be changed?

I'm unsure about the fate of this 7 years old bug, it may be closed as worksforme or incomplete since there's no steps we can use to reproduce the bug easily.

Marco, you are right! Wrong bug, oh. I'll move the comment to the appropriate bug and will adjust the a11y severity here too. Thank you for catching it up!

But from my understanding of the expectations in the STR is that the reported wanted that the Bookmarks panel would close on mouse-out which would also create an accessibility issue (and I assume a usability issue as well) as this panel is explicitly requested by a user (with an icon click), thus should be explicitly dismissed by them (i.e. by a click elsewhere on the screen). I would vote for closing it

Comment 6

[Marco Bonardo [:mak]]

Thank you.
I'm resolving as incomplete because we've not been able to reproduce this problem, so far. We'll need better steps to reproduce here.