1543036 - Keyword input-field overlaps the scrollbar inside One-Click Search Engines section

Status: NEW

(Toolkit :: XUL Widgets, defect, P3)

Description

[Anca Soncutean [:Anca], Desktop Release QA]

Attachment: screenshot issue.png

[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]:

1. Go to about:preferences#search
2. Add several search engines in order to enable the scrollbar inside the One-Click Search Engine section
3. 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.

Comment 1

[Daniel Holbert [:dholbert]]

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

[Daniel Holbert [:dholbert]]

Attachment: screenshot of the DOM involved

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

[Daniel Holbert [:dholbert]]

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.)

Comment 4

[:Gijs (he/him)]

tree-input is a tree widget thing, so moving this bug over to the widget component.

Comment 5

[Neil Deakin]

Is this a duplicate or fixed by any of the other editable tree column issues, or a separate issue?

Comment 6

[Victor Porof [:vporof][:vp]]

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.

Comment 8

[Alice0775 White]

Regression window:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b1a6e2052ea19b8fbf7fde7e3aa25629ff5163be&tochange=4b9f8acdf5f780ed38490f40a74bb33cac3f264d

Comment 9

[Patricia Lawless]

Bulk change of P3 carryover bugs to wontfix for 68.

Comment 11

[Victor Porof [:vporof][:vp]]

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

[Clara Guerrero]

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

Comment 13

[Jens Stutte [:jstutte]]

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)?