Bug Min-Max slider doesn't seem to work with Unity Default Runtime theme.

Below is a gif of me trying to use the built in min-max slider. The results of clicking on either of the handles and moving them around seem to have random results.

Sometimes it grabs the single handle correctly and moves just one, sometimes it decides to slide both of them like as if I'm clicking in the middle area. Also sometimes when I click it snaps the centre of the middle bar to the mouse cursor.



If I set the builder theme to "Dark Editor Theme" or "Light Editor Theme" the handles seem to work ok. But when I flip the theme type to "Unity Default Runtime Theme", everything starts working a little strange.

Should I file a bug ticket with this? In the meantime, is there are way to turn off the middle bar drag entirely to work around this?

 

I also ran into this... my assumption at the moment is just that the element sizes in the default runtime theme lead to some unfortunate overlap between the center bar and the handles, so it might be possible to fix it through styling, but I haven't yet produced a style that solves the issue completely.

 

Unity Devs: Is this a known issue? Should I file a bug report for this? If this is fixed through adding my own styles, as noirb pointed out above it's not clear which style resolves this issue (strangely the handles in the UI theme are actually smaller than the defaults).

 

I had a chance to play with this some more. I had thought that the size/position of the handles was causing them to overlap other elements, making it possible for the pointer events to get picked up by those instead of the handles. After messing around with it some more, though, I don't think the handles are involved in the input processing at all.

With the right handle moved away, you can see that it does overlap the middle bar, rather than starting from the edge.


Making the handles larger didn't help improve usability at all


So, I tried just moving the handles away from the edge of the #unity-dragger element (the blue line). This causes input to pass through them and into the #unity-tracker element (the red line). Dragging on the edge of the #unity-dragger element still resizes the selection, though!


And in fact, if you set the Picking Mode on both handles to Ignore, nothing changes.

It's very important that #unity-dragger is the one handling the input for resizing, because in the default stylesheet the handles are much taller. You can reliably resize the bar if you click within the default handles' width when the pointer is also overlapping the #unity-dragger element, but if you click on part of the handle which extends beyond that element the input is not treated as a resize.


So, usability can be greatly improved by reducing the height of the handles so users aren't tricked into clicking in the wrong location. Unfortunately, there's still a lot of "empty" space that still responds to input and will cause the slider to snap around unexpectedly (but at least with smaller handles you won't be misleading users into clicking there on purpose).

 

Here I've highlighted the background of the parent VisualElement which contains all of the visible input controls, and you can see that clicking anywhere inside that element causes the slider to snap.


Setting the max-height of that element to 0 seems to solve that and gives a much easier-to-use slider.

This messed up the layout for some other parts of the control (e.g. the slider doesn't align with the label, anymore), so some additional restyling is needed to make everything look good, but at least this fixes much of the input-related headaches...

But from a usability and customization standpoint there's still a big issue: since the handles are not actually used for input at all, there doesn't appear to be any way to customize the size of the area the user can press on to perform a resize. It appears to be fixed to 10 pixels on either side of the #unity-dragger element. Maybe it's an intentional choice to do it this way, but in my opinion the thing that would make the most sense would be to provide an element which we can customize. Some applications may want the handles to be located above or below the slider bar, for example, which is currently impossible, and especially on mobile 10px may be too narrow for some users to reliably press in the correct location to perform a resize even after the styling adjustments above.

I think it's also worth looking at the editor theme a little bit. There are a few important differences from the default runtime theme, which I think can be used as guidelines for how to avoid usability issues as much as possible with the current implementation:

• The VisualElement which contains all the input controls is almost the same height as the #unity-dragger element, so it's hard to click somewhere which is visually "outside" of the control and still results in unwanted snapping behavior. (so, it doesn't have to be set to 0 as I did earlier, but definitely try to keep it as small as possible)
  
• No part of the control extends vertically beyond its parent (wheras in the default runtime theme the handles stick out quite a bit).
  
• The handles are 7 pixels wide, which gives a bit of an error margin for the 10-pixel wide "resize" input zone, although that's not very important because they are actually 100% transparent and not used.
• The visible "handles" are part of the background-image applied to the #unity-dragger element. This image is sliced, with the first and last 7 pixels containing the "handles". This could be why the handle elements themselves are ignored when processing input: Unity is not using them
  

Here I have recolored the Editor-themed slider to match the colors of my tests, above. You can see that it's still possible to trigger some unexpected snapping, but realistically the height of the object is so small it's hard to click somewhere that doesn't look like it's part of the slider and trigger a snap.

 

So, to summarize, I think there are two things here which could be considered bugs, or at least should be considered as important feature requests (in case the current behavior is really intentional);

1. There are clearly some important style guidelines for some controls which must be followed to ensure they function as expected and are usable by most users, like the handles of the min-max slider not extending vertically beyond the height of the #unity-dragger element. The default runtime theme should follow these by default, otherwise it will provide a misleading example for developers to follow in building their own content. After this brief investigation, I'm wondering how many other cases of things working slightly weird or differently from how I expected at runtime may be due to the default theme messing things up in a non-obvious manner.
   
2. We really need a way to customize things like the size & location of the area used to capture input. Not just to ensure that it matches the visuals, but also to be able to support multiple platforms (e.g. on mobile it would be useful to be able to increase the size of the "resizable" input area without affecting the rest of the visuals). Having a fixed 10-pixel-wide input area is enough of a problem that many people will end up needing to build their own controls from scratch rather than being able to build on top of the resources Unity provides.
   1. For example, it does not appear to be possible to create a min-max slider with handles like this in the current implementation:
      
3. And, as Spectragate mentioned, the ability to customize some other behaviors, like whether to snap the selection when clicking on the background at all, would be a huge benefit (e.g. in many applications sliders like this will just snap the nearest handle to a clicked point, or ignore clicks outside of the handles altogether).

 

@Spectragate while we wait for comments from the unity devs, here's some USS which I think gives a better starting point for using the min-max slider:

Code (css):

1. .unity-min-max-slider__input {
2.     margin-top: 24px;
3.     min-height: none;
4.     max-height: 6px;
5. }
6.  
7. .unity-min-max-slider__min-thumb {
8.     margin-top: -2px;
9.     min-height: 8px;
10.     max-height: 8px;
11. }
12.  
13. .unity-min-max-slider__max-thumb {
14.     margin-top: -2px;
15.     min-height: 8px;
16.     max-height: 8px;
17. }

 

Wow that is quite the investigation you did there @noirb . I think you summed up really well the current issues with the slider, both from the current bugs to the general usability and customization of it. Impressive!

Any Unity Devs around that have any thoughts on this?

 

Thanks JuliaP - I submitted ticket 1429265 with a link to this thread.

 

Hey!

Any word on this!

Thanks!

 

I disagree with this being fixed as shown in the issue ticket. The slider is terrible to use in game. Is there any way to disable clicking on the tracker so that only the thumbs can be dragged individually?

 

That ticket does address one issue with the MinMaxSlider, but there are still several others mentioned in this thread which have not been addressed, yet. Some of them, as mentioned above, can be mitigated a bit through careful USS adjustments, but we still don't have the ability to customize this control and how it handles user interaction that we really need to be able to use it effectively for runtime applications.

So, here's my implementation: https://github.com/noirb/UIT_RangeSlider
It might still be a little rough around the edges, but it allows you to explicitly toggle whether the thumbs or the whole selection are draggable, doesn't snap around unexpectedly if you mis-click slightly outside of something, and I'm optimistic it will be able to support a wider variety of slider styles (e.g. with the thumbs dangling outside of the slider region), although I haven't pushed this very far in my own projects, yet, so I can't promise it's totally bug-free

 

Thank you so much noirb. I am going to use it to kind of create start and end of shifts for workers in game and this is a huge help.

 

Is there any update on this ongoing unsolved issue? I'm having the exact same issue still, with it jumping to random positions in 2022.2.20f1. I see it says fixed in 2022.2.0b6, which I assume should include my version too, right? But that seems to not be the case. I have commented on the issue tracker saying so.

Thank you

 

Ok, I'm glad you are working on the issue they mentioned, but it seems like the new issue you created is not the issue I'm experiencing. The one marked 'fixed' is. Although, I haven't tested changing the theme. Rereading the og post mentions it working in the other themes, so maybe I'll try that.

To be clear, I want to click the handles and move them, and I also still want to click the bar to shift the whole thing. I don't want to change the style or restrict movement to only the handles. When I click the bar, it moves in unpredictable ways (sometimes it seems to try to move the center of the bar to where you click, sometimes just... not that, and I can't tell what logic it's using), and when I click the handles it sometimes moves the bar instead if I click slightly above or below the vertical center of the handle. I feel like that is exactly what the 'fixed' issue is talking about.

This describes exactly the issue I'm having:
Expected result: The slider always behaves normally
Actual result: Sometimes the slider teleports to a different location or moves instead of extending

I think this issue should be marked as not fixed:
https://issuetracker.unity3d.com/is...s-abnormally-with-unity-default-runtime-theme
Or a new issue should be opened

 

Fair enough. Thank you