Able to reproduce this on the latest canary(54.0.2803.0) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04. This is non-regressed behavior since old chrome version: 34.0.1847.137. Marking this as Untriaged and as Feature request for more inputs on this.

tdresser@ majidvp@ any thoughts on an API to do this?

I know that this doesn't exist today but would it be covered under scroll customization?

eliseosoto@: one workaround that may be to used today is to update the overflow to "hidden" when drag starts and then revert it back when drag ends. That should prevent this behaviour.


dtapuska@: I am not sure if scroll customization is the right API for this. It may be too heavy for such usecases. Also so far scroll customization is limited to direct user-input scrolling and does not cover scrollIntoView, focus driven, drag driven scrolls, or script driven scrolls.

Any reason to keep this RVG? I see nothing confidential here, if no one speaks up I'll unrestrict in a day or two.

eliseosoto@, does Majid's suggestion work for you? I tried it out in the codepen, aside from the scrollbars appearing/disappearing this does seem to work.

An alternate (uglier but less visible) approach might be to overlay an opacity: 0 element over the scroller while the drag is active and move it behind with z-index when the drag ends. This is a bit of extra work and kind of hackish but I've tried it out and it works.

bokan@, actually the visual glitch of the scrollbars appearing/disappearing would be even less desireable.

And I also considered the opacity: 0 overlay but it's too hackish for something that's not critical.

I can wait until a better solution can be implemented.

> Usually that behavior is useful because you can put into view the desired drop zone, but sometimes that is not desired at all.

I feel the existing API to identify what is a valid drop zone should be enough for this. We just have to make the user agent smarter on when to scroll. For example if there is no valid drop zone in that scroller there is probably no point scrolling. I think that should give a good UX and provides control to developer.

Is there any valid usecase where there is a drop zone but it is not desired to allow scrolling to reach to it?

BTW, both Firefox and Safari do not scroll the scroller when dragging.

eliseosoto@, would improving the logic as Majid outlines be enough? If so I'll just rename and relabel this bug to improve the current implementation. Also, can we remove the Googler-only restriction? I don't see anything confidential here.

> Is there any valid usecase where there is a drop zone but it is not desired to allow scrolling to reach to it?

majidvp@ In my project we have a right side vertical drawer with tabbed panels (think Photoshop), these panels can be rearranged by dragging their headers, now these panels can contain scrollable lists.

If I want to rearrange a panel and I accidentally drag over one of these scrollable lists then the list will scroll when all I want is to move a panel, not to insert something into that list.

And yes bokan@, you can remove the Googler-only restriction.

Re #11, in that case, if the scrollable lists don't have a drop zone you should be fine though, right? Though I can see the argument that you might want to drop something else in there, but not a tab. So an API based on what Majid was saying might be to have "Drag Classes", and only if a scroller contains a drop zone for the Drag Class of the currently dragged item would we scroll. OTOH, maybe the simple thing of add a switch to turn off scroll-on-drag is good enough.

In any case, I'll leave this open as this is clearly a gap in the platform.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Marking the status as available given #3 but reducing priority as this is not something we are actively planning to work on at the moment.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot