http://dojo.telerik.com/IkoTO/2
This is just a modified example from the original API Docs demo. All I did was add a spacer div so the page has scroll.
To reproduce: Simply click inside a multiselect, then scroll down to bottom of dropdown results.
You'll see the dropdown closes and then the page starts scrolling.
This would be VERY annoying for any end-user.
Telerik needs to fix this by stopPropagation of the scroll event maybe?
26 Answers, 1 is accepted
Rank 1
Thanks for the feedback. Generally, scroll events cannot be prevented, but we'll see what are our options.
Regards,
Dimo
Telerik
Rank 1
Really? Not sure what you mean by that. Parallax sites are a good example of exerting control over the scroll events.
I seem to recall running into this same issue in some other site I was working on, and preventing propagation was the solution, but that is a fuzzy memory too.
Rank 1
Actually now that I think of it, the scroll event doesn't bubble anyway (would be crazy bad performance), so stopping propagation won't help.
Perhaps what I did in the past project was capture the scroll event and read the current scroll status of the box - and when found at bottom or top of box, then preventDefault()
Rank 1
Here is a demo, which shows how to achieve the desired behavior.
http://docs.telerik.com/kendo-ui/web/dropdownlist/how-to/prevent-close-on-scroll
For the time being, we would like to refrain from implementing this as a built-in feature, as it is hackish and cumbersome. However, you can vote for it on our feedback portal and if there is a high-enough demand, we will consider changing our minds.
http://feedback.kendoui.com/forums/127393-kendo-ui-feedback
Regards,
Dimo
Telerik
Rank 1
I can understand not wanting to put THAT code in Kendo, not sure thats the best solution, though may be the most functional one as a hack from outside.
Don't you think binding mousewheel to document causes way to much unnecessary load?
Why not bind the scroll event to the popup itself on creation of the dropdownlist or don't forget OTHER types of widgets that share the same misfortune (like multiselect and autocomplete)
Sure the solution you made is hacky, and I wouldn't want to include that in Kendo either. But there are better less hacky ways of fixing this oddity in webkit - which just happens to be a browser used by over 60% of the internet.
Really this doesn't need VOTES - it needs a proper fix. Sure it'd be best if webkit would fix it, but we all know that is not likely. Programming around browser flaws is part of our duty as front-end engineers. To turn this into a hacky solution that "meh you guys can vote on adding the fix" is not the way to handle it I'd think.
Bottom line: At least 3 of your widgets suffer from a bad UX due to an oddity (bug?) in the worlds most used browser engine.
Do you :
a) drop a hacky fix into docs and ignore it?
b) implement a real fix into the widgets themselves that is perfectly fine performance wise
c) ignore it in hopes the browser engine sees fit to change the behavior
hmmm
So far, the overall amount of feedback related to the discussed behavior does not imply high severity of the issue. Although we agree that a proper fix would be nice to have in the future, it will require some time and resources for research and testing, and we are currently focused on tasks with higher priority.
Since this code is in the public and open-source Kendo UI Core repository, we are open to suggestions (pull requests) how to achieve the desired end result in the best possible way.
Regards,
Dimo
Telerik
Rank 1
Hi Dimo,
We are facing the same issue. Do you have a fix for this?
Thanks,
Andy
We have not made changes to the MultiSelect implementation with regard to the discussed scrolling behavior, so the previously provided information and workaround still apply.
Regards,
Dimo
Telerik
Rank 1
Here is an alternative approach to the discussed scenario. It requires simpler and shorter code and works as expected on my side. Please check it out. If no side effects appear, we will consider including it out-of-the-box.
http://dojo.telerik.com/OJugu
For the sake of completeness, it is worth mentioning that neither this approach, nor the previous one, target touch devices.
Regards,
Dimo
Telerik by Progress
Rank 1
Rank 1
Rank 1
Rank 1
Rank 1
In kendo.popup.js where kendo essentially closes popups on scrolls and resizes (method name _resize), at least give user the choice to not go along with that. Otherwise at least pass some kind of parameters into the event object of close method, so that user can detect what triggered the close and consequently decide whether to e.preventDefault(). Either shouldn't be hard. Now it's a complete black box and I had to do the ugly global watch to check if the click is outside of popup :/
My assumption is that "slip" implies the mouse cursor moving outside the boundaries of the popup. In this case, closing it would be the better option, otherwise it will end up being misaligned with the originating widget. Surely, this can be worked around with changing the popup's position, but jumping and flickering is inevitable.
Otherwise I agree that a more flexible configuration/behavior capabilities make sense and will pass your feedback to the dev team.
Regards,
Dimo
Telerik by Progress
Rank 1
Hey Dimo,
That assumption is incorrect. Steps to replicate the "slip":
1. Keep your mouse inside the popup
2. Scroll on a wheel back and forth.
Thanks
Rank 1
Its caused by the scrollable element hitting its end of scroll so the scroll event bubbles up the DOM to hit the body which is VERY bad UX.
There is an eloquent fix possible where you aren't attaching scroll events to the window - you guys need to properly investigate and fix your code to provide better UX.
Here you will find a short video testing the described steps. You will notice, that I have scrolled multiple times to the start and the end of the list, but the scroll event did not propagate out of the widget drop-down container. May I ask you to capture similar video demonstrating the issue described?
Darryl, as Dimo already mentioned, we have already included this issue in our backlog for investigation. As soon as our priorities allow it, we will proceed to working on it.
Regards,
Veselin Tsvetanov
Telerik by Progress
Rank 1
Hi Veselin, here it is: http://d.pr/i/udqy
Hope this helps.
I have noticed, that you are testing the sample on Mac. Attached you will find a short video showing the same test in Google Chrome on OS X El Capitan (OS X 10.11). You will notice, that I was not able to reproduce the issue, while scrolling with the Magic mouse or with a PC mouse with a wheel.
Do you test by scrolling using the a Trackpad? If this is the case, I should mention, that the suggested is a workaround and may not cover fully all scenarios.
Talking about the big picture, we will discuss again with the development team this specific behaviour of the drop-downs. We will also consider the suggested changes and other improvements of the UX in this specific scenario.
Regards,
Veselin Tsvetanov
Telerik by Progress
Rank 1
You can check the following article that describes how to handle similar behavior for the DropDownList. By using the same approach you should be able to prevent closing the dropdown when scrolling.
Regards,
Dimitar
Progress Telerik
Rank 1
Hey Bharathwaj,
They tell you to refer to http://docs.telerik.com/kendo-ui/controls/editors/dropdownlist/how-to/appearance/prevent-close-on-scroll, but they're using another way to work around it in their own demo here: http://demos.telerik.com/kendo-ui/autocomplete/index. And the latter way in general is better. See explanation: http://luxiyalu.com/how-to-prevent-body-from-scrolling/