Closed Bug 1543036 Opened 6 years ago Closed 2 years ago

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

Categories

(Toolkit :: UI Widgets, defect, P3)

defect

Tracking

()

RESOLVED FIXED
108 Branch
Tracking Status
firefox-esr68 --- wontfix
firefox-esr102 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox106 --- wontfix
firefox107 --- wontfix
firefox108 --- fixed

People

(Reporter: asoncutean, Assigned: mstriemer, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(6 files)

Attached image 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.
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Layout → Preferences
Product: Core → Firefox

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)

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

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

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

Component: Preferences → XUL Widgets
Product: Firefox → Toolkit

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

Flags: needinfo?(vporof)

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.

Assignee: nobody → vporof
Status: NEW → ASSIGNED
Flags: needinfo?(vporof)
Priority: -- → P3

Bulk change of P3 carryover bugs to wontfix for 68.

I am unlikely to be able to look at this in the near future. Un-assigning for now, please ping if urgent otherwise.

Assignee: vporof → nobody
Status: ASSIGNED → NEW

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

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

Flags: needinfo?(pascalc)
Severity: minor → S4

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.

Flags: needinfo?(mstriemer)
Severity: S4 → S3
Flags: needinfo?(mstriemer)
Attached image edit-bookmark.png

This also affects the edit bookmark panel when renaming a folder

See Also: → 1708159
Assignee: nobody → mstriemer
Status: NEW → ASSIGNED
Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/107cba532db8 Account for scrollbar when editing a tree r=NeilDeakin
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

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 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(mstriemer)

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.

Flags: needinfo?(mstriemer)
QA Whiteboard: [qa-108b-p2]
Attached image Screenshot 2022-11-15

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?

Flags: needinfo?(mstriemer)

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.

See Also: 1805367
Duplicate of this bug: 1836624
Regressions: 1881852
No longer regressions: 1881852
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: