1454363 - Unify the "popup" and "popup-scrollbars" bindings

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, task, P1)

Description

[:Paolo Amadini]

The "popup-scrollbars" binding provides drag-to-scroll behavior in the popup of HTML <select> elements and XUL <menulist> elements.

This binding is not used by the Places menus, since they have a separate implementation of the drag-to-scroll behavior. These menus actually support reordering items with drag-and-drop, while <select> and <menulist> don't.

Drag-to-scroll is not discoverable, and is probably not needed at all on Linux and Windows where there are scrollbars visible when the element overflows. On Mac, however, the scrollbar disappears by default after a short time, as noted in bug 895499, and doesn't come back until the popup is closed and reopened.

This Mac behavior of hiding the scrollbar may be limited to devices that have a scroll wheel or trackpad available, but I don't have a way to verify this. If this was the case, we might assume that Mac users who only have a mouse without a scroll wheel would still be able to access all items without closing and reopening the popup or using the keyboard, and remove the drag-to-scroll behavior.

We might also remove this behavior anyways if we consider that this potential regression would be limited to very old Mac models, and modern models would very likely have a trackpad or scroll wheel.

Gijs, any thoughts?

Comment 1

[ExE Boss]

We might be able to merge this with the work being done in bug 1431246 so that we only have one scrollbar implementation instead of multiple implementations.

Comment 2

[:Gijs (he/him)]

(In reply to :Paolo Amadini from comment #0)
> This Mac behavior of hiding the scrollbar may be limited to devices that
> have a scroll wheel or trackpad available,

Whether scrollbars disappear is configurable in system preferences.
 
> We might also remove this behavior anyways if we consider that this
> potential regression would be limited to very old Mac models, and modern
> models would very likely have a trackpad or scroll wheel.
> 
> Gijs, any thoughts?

I'm afraid I don't understand what the question is.

I'm not familiar with this binding. I can't tell if it does anything useful (and comment #0 doesn't really tell me). What is "drag to scroll" behavior? That is, I can mousedown on an item in http://output.jsbin.com/kaqorutiqu and move the mouse, and the list scrolls. Is that accomplished by this binding? Or not? Are you proposing removing that behavior, or moving it somewhere else (also not explicit in comment #0), or something else still ? comment #1 makes things murkier still...

I also don't think I'm the right person to ask, regardless... :mconley and :jaws both have more experience with our <select> to-the-parent implementation, so I think they're better people to ask...

Comment 3

[:Paolo Amadini]

(In reply to :Gijs (he/him) from comment #2)
> That is, I can mousedown on an item in http://output.jsbin.com/kaqorutiqu
> and move the mouse, and the list scrolls. Is that accomplished by this
> binding?

Yes.

> Are you proposing removing that behavior

Yes, so we can remove the binding entirely.

> I also don't think I'm the right person to ask, regardless... :mconley and
> :jaws both have more experience with our <select> to-the-parent
> implementation, so I think they're better people to ask...

Comment 4

[:Paolo Amadini]

(In reply to ExE Boss from comment #1)
> We might be able to merge this with the work being done in bug 1431246 so
> that we only have one scrollbar implementation instead of multiple
> implementations.

The work in bug 1431246 is unrelated, and I don't think this binding is used in-content.

Comment 5

[:Gijs (he/him)]

FWIW, it seems Safari uses a native menu with little arrows at the ends like we do in the bookmarks (toolbar) menu dropdown and so on. There's no scrollbar, but there *is* click to drag behavior. Ditto for Chrome (on macOS, that is). If we can somehow use the native implementation, I guess that'd be preferable, but otherwise, off-hand I don't think removing stuff that essentially provides parity with native implementations is a good idea.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah, they, unfortunately, have similar names but they are used in different and unrelated places.

Comment 7

[ExE Boss]

(In reply to :Paolo Amadini from comment #0)
> The "popup-scrollbars" binding provides drag-to-scroll behavior in the popup
> of HTML <select> elements and XUL <menulist> elements.

(In reply to :Paolo Amadini from comment #4)
> (In reply to ExE Boss from comment #1)
> > We might be able to merge this with the work being done in bug 1431246 so
> > that we only have one scrollbar implementation instead of multiple
> > implementations.
> 
> The work in bug 1431246 is unrelated, and I don't think this binding is used
> in-content.

Well, HTML `<select>` elements are used in-content, but I’m not really sure about their drop-downs given bug 1390445.

Comment 8

[:Paolo Amadini]

(In reply to :Gijs (he/him) from comment #5)
> FWIW, it seems Safari uses a native menu with little arrows at the ends like
> we do in the bookmarks (toolbar) menu dropdown and so on. There's no
> scrollbar, but there *is* click to drag behavior.

In fact you don't even need to click, just place the cursor just above or below the dropdown menu.

If we think parity on this particular interface is important, then we'd probably have to reimplement this functionality in some other way when we get around to tackling this binding.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

I don't think we should remove this functionality without any data that says this is not used in practice. Safari has the buttons at the top and bottom that can be hovered to scroll, and Chrome and Edge have similar drag-to-scroll behavior as we do.

Can the drag-to-scroll functionality get merged upstream in to the "popup" binding?

Comment 10

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336

Comment 11

[:Paolo Amadini]

(In reply to (away Dec 24-26, Dec 31-Jan 1) Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #9)
> Can the drag-to-scroll functionality get merged upstream in to the "popup"
> binding?

Yes, I think we can do this. I'll fix bug 1454360 first by migrating the inner element to "arrowscrollbox", which is what I suggested in bug 1454358 comment 1.

Comment 12

[:Paolo Amadini]

Attachment: Bug 1454363 - Unify the "popup" and "popup-scrollbars" bindings. r=bgrins

Depends on D15276

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0fe293d9f494
Unify the "popup" and "popup-scrollbars" bindings. r=bgrins

Comment 14

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/0fe293d9f494