New Library info pane overlaps the list of bookmarks
Categories
(Firefox :: Bookmarks & History, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox61 | --- | unaffected |
firefox62 | --- | wontfix |
firefox63 | --- | wontfix |
firefox64 | --- | wontfix |
firefox65 | --- | fix-optional |
firefox66 | --- | fix-optional |
People
(Reporter: gingerbread_man, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [fxsearch])
Attachments
(1 file)
49.28 KB,
image/png
|
Details |
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•3 years ago
|
Comment 1•3 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•3 years ago
|
Reporter | ||
Comment 2•3 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•3 years ago
|
||
thanks for additional testing, bumping a bit, still not a blocker, imo.
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 4•3 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•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Bug #1468992 was fixed some time ago. Any update on this?
Updated•3 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•2 years ago
|
Comment 11•2 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•1 year 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•1 year ago
|
Comment 14•1 year 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•1 year ago
|
Comment 15•1 year 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•1 year ago
|
||
it's not matter of choosing an option, it's matter of making a patch.
Comment hidden (advocacy) |
Description
•