Scrollbar permanently disappears in <select> dropdowns. |
|||||
Issue descriptionScrollbar disappears in the dropdown of native <select> element and may never re-appear. See video. https://drive.google.com/a/chromium.org/file/d/0B_YxmewO52CgMWM5WTlZYUNuam8/view?usp=sharing I see that scroll bar appears back only if some <option> doesn't exactly fit the dropdown. Than you can hover over it, and scroll bar will appear. But the video shows an example when displayed dropdown is evenly divided into blocks of <option> elements, so no element is "partially shown", and scroll bar never appears.
,
Jul 18 2017
Just tried a simple example https://jsfiddle.net/mrz0j8ym/2/, it works as expected: 1. mouse click drop, scrollbar show then fade out 2. mouse scroll, scrollbar show then fade out I also check same page in beta channel. I think it is ok. see attachment.
,
Jul 18 2017
You are doing scrolling action on a touch pad. Yes, this works. But if you are configuring ChromeBox (which doesn't have any embedded input devices), you won't have a touch pad. And you'll have to use mouse wheel for the same. But I was told that scroll bad should appear just by hovering over it. And it does not. It appears if you hover over partially hidden option, but if there are no such options, it will require you to scroll first.
,
Jul 18 2017
Yes, it does not show for hover because this is not a compositor scrollbar.
,
Jul 18 2017
Hmm, it'd be nice if we could make popups composited but I'm not sure how straightforward that would be. Chao, could you see how hard it would be to add the "appear on hover" behavior for non-composited scrollers?
,
Jul 18 2017
We should save invisible scrollbar in HitTestResult, then in mouse enter[1] post a delay fade-in/show if it is hidden, also need mouse move and leave for fade-out/disappear. [1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp?rcl=4a6917c66d843b2aa3978ebbd59b2750c4b62895&l=354
,
Jul 25 2017
So we don't create a compositor at all for popups, I don't think spinning up all of CC would be a good idea just for a popup. Tom/Sebastien, would we be ok with <select> popups having old style scrollbars while the rest of the content has overlays? That's one possible fix. Long-term we'll be able to solve this but it'll require some larger (likely multi-quarter) work. How critical do we see this as? There is a simple work around by scrolling with the arrow keys, that'll bring back a scrollbar. It's a bit unfortunate but hopefully there shouldn't be many people without a wheel?
,
Jul 25 2017
I'm comfortable with dropdowns showing a scrollbar. We've decided we want to make the UI accessible for users who can't use 2-finger scroll / scrollwheel, so we should apply the same rule to dropdowns.
,
Aug 15 2017
Chao looked into this and mixing scrollbar themes is a bad idea technically. The scrollbar theme is static so if we change it then the page in the background could start creating classic scrollbars (or other tabs in the same renderer). I had another idea though which I think should be a rather simple fix. We just disable fade out on the <select> popups. The scrollbar might obscure some parts of the popup but I think this isn't a big deal like for a regular web page since the format of the content in a <select> is restricted. Each item is clickable across the whole row so there's no way for the scrollbar to prevent the user from selecting an item. If an item is obscured by the scrollbar it can still be seen since the scrollbars are translucent. Does that sound ok?
,
Aug 18 2017
Yep, sounds reasonable to me!
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd4e4e45a2551c6c04345a13581901bc71ee7d83 commit bd4e4e45a2551c6c04345a13581901bc71ee7d83 Author: chaopeng <chaopeng@chromium.org> Date: Thu Sep 07 22:43:38 2017 Prevent fade out Overlay Scrollbar for <select> popup. Since we are not able to make cc overlay scrollbar for popup window <select>. In this patch, we prevent Overlay Scrollbar fade out for <select> popup. Bug: 745161 Change-Id: I7dff32237b2501e39ba3c1314bd35d0cf0cf0638 Reviewed-on: https://chromium-review.googlesource.com/600708 Reviewed-by: Rick Byers <rbyers@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Commit-Queue: Jianpeng Chao <chaopeng@chromium.org> Cr-Commit-Position: refs/heads/master@{#500417} [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/core/exported/WebPagePopupImpl.cpp [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/platform/PlatformChromeClient.h [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/platform/scroll/ScrollableArea.h [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/platform/scroll/ScrollableAreaTest.cpp [modify] https://crrev.com/bd4e4e45a2551c6c04345a13581901bc71ee7d83/third_party/WebKit/Source/platform/scroll/ScrollbarTestSuite.h
,
Sep 16 2017
,
Jan 22 2018
,
Jan 23 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bokan@chromium.org
, Jul 18 2017Components: UI>Shell
Labels: Hotlist-Input-Dev
Owner: chaopeng@chromium.org