Keyword input-field overlaps the scrollbar inside One-Click Search Engines section
Categories
(Toolkit :: UI Widgets, defect, P3)
Tracking
()
People
(Reporter: asoncutean, Assigned: mstriemer, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Attachments
(6 files)
[Affected versions]:
- 66.0.2
- 67.0b9
- 68.0a1 (2019-04-09)
[Affected platforms]:
- Windows 10 x64
- macOS 10.13
- Ubuntu 18.04 x64
[Steps to reproduce]:
- Go to about:preferences#search
- Add several search engines in order to enable the scrollbar inside the One-Click Search Engine section
- Click inside the Keyword column for any search engine
[Expected result]:
- The keyword input-field doesn’t overlap the scrollbar
[Actual result]:
- The keyword input-field overlaps the scrollbar
[Regression range]:
- I could restrain the regression range to 2018/10/03 - 2019/01/05. ( see the pushlog). Unfortunately some nightly builds are broken between these dates, when it comes to add new search engines.
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
From a layout perspective, this is the correct result. The textbox here is a sibling (not a descendant) of the scrollable pane.
So, this is a bug in the Preferences UI code here. (If this textbox is expected to be part of the scrollable content, then we should make it part of that content rather than a sibling of the scrollable area)
Comment 2•6 years ago
|
||
Here's a screenshot of inspector showing the DOM that's involved here.
Notice that the scrollable hbox (whose scrollbar is highlighted in the DOM inspector) is the previous-sibling of the "floating" textbox here. This is why the textbox is correctly stomping on top of the scrollable area (including its scrollbar).
Comment 3•6 years ago
|
||
Note for anyone investigating this on the frontend side: you can make this reproduce more easily if you open the DevTools Inspector, search for "tree-input" (should only find one element), and remove the hidden="true"
attribute from that element.
That makes the textbox show up and stop disappearing when it loses focus. (You still need to add search engines [or find another way of causing overflow] to make the scrollbar show up so that the overlap is obvious, though.)
Updated•6 years ago
|
Comment 4•6 years ago
|
||
tree-input
is a tree widget thing, so moving this bug over to the widget component.
Comment 5•6 years ago
|
||
Is this a duplicate or fixed by any of the other editable tree column issues, or a separate issue?
Comment 6•6 years ago
|
||
It's possible this was caused by the tree de-xbl-ification, however the layout seems correct and the nesting wasn't changed in the process. A more accurate regression range would be useful. I'll do a couple of manual builds.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 9•5 years ago
|
||
Bulk change of P3 carryover bugs to wontfix for 68.
Comment 11•5 years ago
|
||
I am unlikely to be able to look at this in the near future. Un-assigning for now, please ping if urgent otherwise.
Comment 12•5 years ago
|
||
Hi,
I've tested this using the latest Nightly version 74.0a1 (2020-02-03) (64-bit) for Windows 10 pro and I’m able to reproduce the issue. Based on this I will mark firefox74 flag as affected as well.
Best,
Clara
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Hi Pascal, actually this regression is quite old. Should we continue to track it as a regression for 74 (be it new or carry-over)?
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Comment 15•2 years ago
|
||
The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:mstriemer, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 16•2 years ago
|
||
This also affects the edit bookmark panel when renaming a folder
Assignee | ||
Comment 18•2 years ago
|
||
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Comment 20•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 21•2 years ago
|
||
The patch landed in nightly and beta is affected.
:mstriemer, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox107
towontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 22•2 years ago
|
||
This is a pretty minor and longstanding visual issue. I don't know that it's worth the trouble of uplifting it but I can put in the request if someone disagrees.
Updated•2 years ago
|
I can still reproduce this issue on Firefox 108.0b1 and Nightly 109.0a1 on macOS 12, Windows 10, Ubuntu 22. Should I re-open the bug?
Updated•2 years ago
|
Comment 24•2 years ago
•
|
||
Please ignore the above attachment since the scrollbar faded before I could capture it properly in a screenshot. Here's a better one from Fx Nightly on macOS 12. I filled bug 1805367 as a regression, potentially caused by this fix.
Description
•