"No bookmarks" message on empty bookmarks toolbar cannot be used as a drop target for new bookmarks, making bookmarks creation there error-prone
Categories
(Firefox :: Bookmarks & History, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox83 | --- | unaffected |
firefox84 | --- | wontfix |
firefox85 | --- | verified |
People
(Reporter: soeren.hentzschel, Assigned: Gijs)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
STR:
- enable the bookmarks toolbar
- make sure that the bookmarks toolbar is empty
- drag an open tab to the bookmarks toolbar
Actual:
It depends on where you released the tab. With a German build and the display resolution of my MacBook Pro the new empty state text (introduced in bug 1674091) makes ~ 40 percent of the bookmarks toolbar and it's not possible to use this space for bookmarking a page. Instead of bookmarking the page the tab will be moved to a new window. This is a completely different result and therefore an unexpected usability regression.
Expected:
The page should be bookmarked no matter where I release the tab, even if I release the tab on the empty state text. This action should not move the tab to a new window.
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1674091
Comment 2•4 years ago
|
||
I'm not sure how the text was introduced, but it should ideally be transparent to drop operations, it sounds like it's just being introduced as a box without any drop handling.
Comment 3•4 years ago
|
||
Ah it's not part of personal-bookmarks, so it won't handle drops at all :(
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Assignee | ||
Comment 6•4 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #3)
Ah it's not part of personal-bookmarks, so it won't handle drops at all :(
I chatted with Jared, the reason for this (ie why not just make it part of the personal-bookmarks item?) is that we want to be able to show the item when the personal-bookmarks item is not on the toolbar, so that again, the toolbar is not completely empty without anything on it.
Comment 7•4 years ago
|
||
bugherder |
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
Comment on attachment 9191017 [details]
Bug 1678921 - make empty toolbar disclaimer take up no horizontal space, so the entire toolbar functions as a drag target for bookmarks (beta patch), r=jaws
Beta/Release Uplift Approval Request
- User impact if declined: Issues with dropping URLs/bookmarks on the places toolbar when it's empty
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: See comment #0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a relatively minor JS + CSS change.
- String changes made/needed: none
Assignee | ||
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Comment on attachment 9191017 [details]
Bug 1678921 - make empty toolbar disclaimer take up no horizontal space, so the entire toolbar functions as a drag target for bookmarks (beta patch), r=jaws
Approved for 84.0b8.
Comment 11•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Comment 12•4 years ago
|
||
I've reproduced the issue on Firefox 85.0a1 (20201116210217) and verified the fix on Nightly 85.0a1 (20201204094005) and Beta 84.0b8 (20201203211213)
Reporter | ||
Comment 13•4 years ago
|
||
I can confirm that the reported issue is fixed but now the link in the placeholder message is no longer clickable. Should this ticket be reopened or do you prefer another ticket?
Assignee | ||
Comment 14•4 years ago
|
||
(In reply to Sören Hentzschel from comment #13)
I can confirm that the reported issue is fixed but now the link in the placeholder message is no longer clickable. Should this ticket be reopened or do you prefer another ticket?
The answer to this question kind of depends on whether we can come up with a fix that is additive, or whether we need to back this fix out completely and fix the problem some other way.
We can make the link clickable again by giving it position: relative;
and a z-index. But of course, that then means that if you drag something to the link, it stops creating a bookmark 🙃. Having that not work only for the link is better than not having it work for the entire message, but not a lot better / more understandable for users. We can't just give the empty bookmarks toolbar pointer-events: none
to make the link work, either, because of course then the drag handling will go back to not working, but for the entire toolbar...
Still trying to figure out if there's a better way here.
Assignee | ||
Comment 15•4 years ago
|
||
OK, per discussion with Jared and Ryan, we're going to at least back the fix from this bug out of beta. I'll file a follow-up for 85 where we'll try and actually fix both the original issue, the link clicks, and bug 1678951.
Ryan, needinfo for the backout as per our discussion.
Comment 16•4 years ago
|
||
backout |
Backed out for 84.0rc1.
https://hg.mozilla.org/releases/mozilla-beta/rev/38109b4b3b362f55d059569ddc060275be59ddf4
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Description
•