Click the dropdown for week (ie Week 15), it looks like Week 15 is the last element you can select because there is no indication there is more to scroll. Even though I know about this it has bitten me several times. Chrome and Safari have an indicator.

This problem goes back to FF 24, which was the first release in which we turned on overlay scrollbars.

I should add that I tested on OS X 10.7.5, so this isn't Mavericks-specific.

This bug doesn't effect *all* select drop downs. For example the ones in this bug aren't effected.

Thanks for filing this bug! I remember speaking with mconley (I believe) when we first started testing overlay scrollbars. He mentioned precisely this issue with select boxes, but I can't seem to find a bug for this. Note that the scrollbars actually do appear, but they usually fade away before you had a chance to open the select box. If you test this very quickly, refresh the page and open the select box. You will see how the scrollbars fade away. We should make sure that they display every time when first opening the select box.

Yes, it is an existing issue for a while that I just got around to filing now. I see the issue on 10.8 as well. (In reply to Stephen Pohl [:spohl] from comment #4) > We should make sure that they display every time when first > opening the select box. This will improve the situation, but I'm not sure it will be enough. When the select first opens you are probably looking at all the options that just appeared and may not notice the scroll bars. Then after you've scanned the options the scroll bars aren't there anymore. Chrome and Safari have persistent indicators that you can scroll. I think this is a slightly different situation from all other places where scrollable areas appear in the browser.

Timothy, have you noticed that not all select drop downs are effected by this bug?

> Timothy, have you noticed that not all select drop downs are effected by this bug? I just retested with the select drop downs on this bug's page, and now I see that even they're effected by this bug, but only some of the time. For example the "Component" combo box (currently set to "Widget : Cocoa"): If I reload the page, the first time I click on the "Component" combo box I see the overlay scrollbar for a few seconds. But I don't see it at all on subsequent attempts until I reload the page again. This issue is distinct from whether or not we should use overlay scrollbars at all in combo boxes, and whether or not we should (when appropriate) display a triangle/arrow at the top or bottom of a drop-down list.

I can't say whether it affects all selects or not, but it does affect some of them.

Timothy and Stephen, do you think this is a fair description of this bug?

Works for me. :-) We should probably figure out two things: 1. Should we have permanently visible arrows, indicating that there's more in the list? Possibly greying them out once we hit the top or bottom? 2. Should scrollbars be permanently visible, or is it enough to make them appear for a few seconds when opening the select box?

Just noticed that Safari and Chrome never use scrollbars in combo-box drop-down lists, even when overlay scrollbars are disabled (for example because you've plugged in a mouse). The only scroll indicator they use is a triangle/arrow at the top and/or bottom of the drop-down list. I'm not saying we should necessarily imitate them, but I do think we should look at other browsers' (and possibly other apps') behavior before we decide.

> Just noticed that Safari and Chrome never use scrollbars in combo-box drop-down lists We on the other hand have (I think) always used them (I tested back to FF 15), even before we started implementing overlay scrollbars. So it'd be more consistent for us to keep the overlay scrollbars and change their behavior. I also think it'd be more consistent not to use triangle/arrows at the top or bottom of a drop-down list ... but I'm not sure that means we *shouldn't* use them.

> I tested back to FF 15 And now back to FF 4.

My gut tells me we should just make sure overlay scrollbars appear (temporarily) every time you open any drop-down list. That's the most conservative change. We can save more ambitious changes for later (and for other bugs).

I'd support this conservative approach to this bug.

I have a testcase available as attachment 8369309 [details].

Hi, I didn't see this bug report when I logged 966874. It's great to see others have reported and have begun working on the issue. I see there hasn't been any update since 2013 - has there been any progress to report? Regarding the approach to the issue - I don't think it's a matter of being conservative or not, but a matter of restoring functionality. A scroll bar plays an important roll in signifying that additional options exist and allow users to access/select those additional values. The way I see it, the scroll bar for drop down lists needs to be functional as a matter of urgency for Mac Firefox users. If it's still open for discussion I would vote to restore the scroll bars to the way they functioned prior to the change, the way they functioned in FF 23. Are there issues with this approach, is that why it wasn't raised previously?

(In reply to Steven Michaud from comment #14) > My gut tells me we should just make sure overlay scrollbars appear > (temporarily) every time you open any drop-down list. That's the most > conservative change. We can save more ambitious changes for later (and for > other bugs). What do we need to do this? Call ActivityStarted, ActivityOccured, ActivityEnded on the ScrollbarActivity from the relevant places when we show the dropdown?

Calling ScrollbarActivity::ActivityOccurred will be sufficient. Note that it's the scrollbar owner who has to call this on its ScrollbarActivity member [1]. I think what needs to be done is: 1. Detect when a dropdown menu is opened and notify the scrollbar owner. 2. Scrollbar owner to call ActivityOccurred on its ScrollbarActivity member. ActivityStarted, ActivityEnded etc. will be handled by the ScrollbarActivity class itself. We currently have nsHTMLScrollFrame, nsXULScrollFrame and nsTreeBodyFrame with ScrollbarActivity members. I forget which of these are used for dropdown menus. [1] http://mxr.mozilla.org/mozilla-central/source/layout/generic/ScrollbarActivity.h#42

This bug happens on non-e10s only; the new e10s <select> (bug 1154677) is implemented with XUL popup UI, and it correctly shows the scroll bars. We should close this bug out when we ship e10s.