New Library info pane overlaps the list of bookmarks
Categories
(Firefox :: Bookmarks & History, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr91 | --- | wontfix |
firefox61 | --- | unaffected |
firefox62 | --- | wontfix |
firefox95 | --- | wontfix |
firefox96 | --- | wontfix |
firefox97 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | wontfix |
firefox101 | --- | verified |
People
(Reporter: gingerbread_man, Assigned: jteow, Mentored)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [fxsearch][lang=js])
Attachments
(2 files)
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 20180626220124 https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ef4f9baee078151c09dc59dd2b38be8fef40498c&tochange=11f29bd57a65909d20fdf96677ba95596c953f89 1. Show All Bookmarks. 2. Select a folder with too many items to fit in view vertically, so that a vertical scrollbar shows. 3. Scroll down to the bottom. 4. Click the last item to select it. Actual results: The lower pane expands vertically, but the scroll position doesn't adjust. This results in the list of bookmarks being partially obscured, including the bookmark that was just selected. Expected results: The lower pane expands if necessary, without obscuring the list of bookmarks.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Not a big deal. Anyway we should first fix Bug 1468992, and then we can decide to either make the panel a fixed height, so it doesn't flicker, or scroll the tree so the selected item is always visible after updating the pane.
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
Alternate STR, a bit more of a nuisance than comment 0: 1. Show All Bookmarks. 2. Select a folder with too many items to fit in view vertically, so that a vertical scrollbar shows. 3. Scroll down to the bottom. 4. Middle-click the last item to open it in a new tab. Actual results: The bookmark doesn't open. The lower pane expands vertically, but the scroll position doesn't adjust. This results in the list of bookmarks being partially obscured. Expected results: The bookmark opens in a new tab.
Comment 3•5 years ago
|
||
thanks for additional testing, bumping a bit, still not a blocker, imo.
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
(In reply to Gingerbread Man from comment #2) Affects right clicks as well. A right click won't open the context menu of the bookmark as expected. If the new location of a text field ends up where you right clicked, it will instead open the context menu for that text field, otherwise no context menu appears at all.
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Bug #1468992 was fixed some time ago. Any update on this?
Updated•4 years ago
|
Too late to fix in 64. Marking this issue as fix-optional for 65; if you land a patch in nightly and think it's low-risk for beta, please request uplift.
Updated•4 years ago
|
Comment 11•4 years ago
|
||
The general thoughts for fixing this are:
- Having the Library window revert to horizontal alignment of fields would be acceptable.
- It would possibly be best to separate the styles of the library window and the Star UI panels but we're not sure how easy that will be.
So if we can un-share we could then revert the changes in bug 1459885 for just the library window.
Comment 13•3 years ago
|
||
Any update on fixing this issue? As Mark Banner said, reverting changes in bug 1459885 for just library window looks appropriate and easy fix (at least from user perspective ;) ).
It's kinda extremely annoying to manage bookmark folder with bookmarks exceeding visible area (please see attachment from duped bug #1477541 - https://bug1477541.bmoattachments.org/attachment.cgi?id=8994005 ).
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Mark said we can revert changes if we can unshare, that's unlikely for now.
I said what I think we should do in comment 1.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #1)
[...] Anyway we should first fix Bug 1468992
It's fixed for over 1 year.
(In reply to Marco Bonardo [:mak] from comment #1)
and then we can decide to either
make the panel a fixed height, so it doesn't flicker, or scroll the tree so
the selected item is always visible after updating the pane.
I support unchanged, permanent and constant height of panel, as you said, no annoying flickering, so I'm choosing gate... err ...option number 1. ;)
Comment 16•3 years ago
|
||
it's not matter of choosing an option, it's matter of making a patch.
Comment hidden (advocacy) |
Comment 20•1 year ago
|
||
After initializing the pane, we should ensure the selected item, if present, is scrolled into view. The treeview has an ensureRowIsVisible method that could be used. the code for the library lives in https://searchfox.org/mozilla-central/source/browser/components/places/content/places.js
Comment 23•1 year ago
|
||
I hope this is appropriate.
The reason the link does not open is because it is not under the finger for the 2nd part of the click event. It moves up and the finger now points to the next in line link.
Seems to me the best solution would be to increase the bottom section to prevent the link(s) from moving when the bottom is selected.
Any change in the link list will cause the user to be on a wrong link for the complete click event.
Comment 24•1 year ago
|
||
a potential solution in comment 20, but it should be tested.
Comment 25•1 year ago
|
||
Hello Marco,
I am trying to work on this bug, in accordance with your suggestion on comment 20
Thanks
Comment 26•1 year ago
|
||
If you move the selected link into view wouldn't that possibly make the pointer NOT be pointing to the desired link?
Resizing the window would keep the bottom of the view in the same place therefore the pointer would stay on the desired link.
Comment 27•1 year ago
|
||
Resizing the details pane has other downsides, it would take up major space while being mostly empty on non-uris. I'm not sure there's a win-win solution here, and the Library is in low-maintenance mode, because we'd really like to move it into something newer in-content, where we'd also have more available space for its contents.
You're right that the right and middle click operations should work on the appropriate element, not on the panel, and the fix should ensure those work, even with an automated test. If that becomes too complicate we're open to evaluate alternative approaches.
(feel free to work on this, of course).
Comment 28•1 year ago
|
||
There are 4 rows used for the title of the field. Could the name (Name, URL, Tags, Keyword) be moved to the same line/row as the text field? That may be sufficient. It sure is a nuisance the way it is. I have too many bookmarks.
Sorry I don't have the talent to work on this bug. :)
Reporter | ||
Updated•1 year ago
|
Comment 29•1 year ago
|
||
After digging a bit I found that my suggestion was possibly a change in the other directions.
https://bugzilla.mozilla.org/show_bug.cgi?id=1459885
===
Dão Gottwald [::dao]
Assignee
Description • 4 years ago
Instead of:
Name: []
Folder: [][v]
Tags: [_______][v]
the new layout looks like this:
Name:
[_____________]
Folder:
[__________][v]
Tags:
[__________][v]
Comment 30•1 year ago
|
||
We can't change the UI without specific approval from UX, and at the moment that team is extremely busy, so we must fix it in code if we want this to proceed sooner.
Comment 31•1 year ago
|
||
Set release status flags based on info from the regressing bug 1459885
Updated•1 year ago
|
Comment 32•1 year ago
|
||
Set release status flags based on info from the regressing bug 1459885
Comment 33•1 year ago
|
||
FWIW I have been using userchrome.css
to hide the keyword field as a partial workaround ever since the "More/Less" toggle was removed, but things seem to have gotten worse after migrating from ESR78. Two extra lines of description, Use tags to organize and search for bookmarks from the address bar
and Use a single keyword to open bookmarks directly from the address bar
were added to the library infopane. I had originally assumed these would only persist during some onboarding grace period but alas.
Updated•1 year ago
|
Assignee | ||
Updated•11 months ago
|
Reporter | ||
Updated•11 months ago
|
Assignee | ||
Comment 34•11 months ago
|
||
Comment 35•9 months ago
|
||
Pushed by jteow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2ca189b8925d Scroll to bookmark in bookmark library on initial selection when it's not visible r=mak
Comment 36•9 months ago
|
||
bugherder |
Updated•9 months ago
|
Updated•9 months ago
|
Comment 37•9 months ago
|
||
I managed to reproduce this bug on Firefox 100.0(20220428192727) on macOS 11. Confirmed as fixed on Firefox 101.0b4(20220508185621) and Nightly 102.0a1(20220509190429) on macOS, Ubuntu 20.04 and Win10-64 bits.
Comment 38•5 months ago
|
||
We're backing out the fix that landed here in bug 1786518 due to annoying regressions it caused, we'll instead look into a UI solution like bug 1786322 that should remove risk of more edge cases
Description
•