"Page bookmarked" panel hides shortly after it's opened

RESOLVED DUPLICATE of bug 1322129

Status

()

Firefox
Bookmarks & History
RESOLVED DUPLICATE of bug 1322129
a year ago
a year ago

People

(Reporter: 684sigma, Unassigned)

Tracking

({regression})

52 Branch
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
I have a problem with Firefox 52. It doesn't happen in Firefox ESR 45. It also doesn't happen in Chrome 57.
Sometimes "Page bookmarked" panel disappears and saves bookmark without my consent.
It happens unpredictably, however, I noticed one specific scenario when it happens

1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=1345479
2. Press Ctrl+D, move mouse outside of "Page bookmarked" panel
3. Wait a bit (because I'm in no rush, and need some time to use it at my discretion: read the page or think about bookmark name, or think about the folder where I'm going to put this bookmark)

Result: "Page bookmarked" panel disappears, and bookmark is saved as is
Expected: "Page bookmarked" panel should only close when user explicitly closes it (like other panels)
(Reporter)

Updated

a year ago
Keywords: regression

Updated

a year ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1322129
(Reporter)

Comment 2

a year ago
I'm not the only one who has this regression.
I've read the but that broke "Page Bookmarked" panel completely (Bug 1219794), and found bug 1290011.
Could you please explain why Bug 1290011 (which is exactly the same) was NOT closed for the same reason as Bug 1322129? Apparently, more people were involved in discussion of Bug 1290011, and they did NOT hurry with approving this regression. That bug was mistakenly resolved as duplicate, but it still happens.
Flags: needinfo?(yfdyh000)

Comment 3

a year ago
I'm not sure I understand them correctly.
Flags: needinfo?(yfdyh000) → needinfo?(mak77)
Similar bugs can have different outcomes, depending on a bunch of things, the participating people, the clarity of the bug, the time it is filed. If a regression bug is filed closer to the behavior change, it's likely more discussion will happen, cause we value feedback and we evaluate it especially after the behavioral change hits users. Second from that time to now many things changed, bugs were fixed and the behavior is now more coherent.

That bug originally started like this one, but it was close to the landing change, so discussion happened and some pain points were identified and fixed. The bug mutated in a way that the opening comment cannot cover. This is a limitation of bugzilla and possibly a mistake in the way we (ab)use it. Right or wrong, doesn't matter much at this point.

The fact is out of those discussions come decisions about what to consider wontfix and what worth fixing.
If the request is "the panel shouldn't autoclose", it's a wontfix. If there is a clear use case where the user is _ACTIVELY_ interacting with the panel (typing, moving mouse over it) and it closes, then it's a bug.
Flags: needinfo?(mak77)
You need to log in before you can comment on or make changes to this bug.