Up until 1.10.0, the ui.slider widget would intercept 'click' events on the <a> tag used for the draggable slider handle. Starting with 1.10.1, the ui.slider widget utilizes the widget factory's '_on' method to delegate events.
Using the direct event handling in 1.10.0, the 'click' event was handled and the default action cancelled regardless of the state of the slider widget (enabled/disabled).
In 1.10.1, the '_on' method only invokes the 'click' handler if the slider widget is enabled (per documentation). However, the slider widget does not expose any configurable option to control this behavior. When a user clicks on the slider handle in a disabled state, the 'click' event escapes to the browser and the browser attempts to navigate to '#' as specified by the <a> tag's href attribute.
When using single-page application frameworks with a router, like Spine or Backbone, this causes the router to pick up on the "change" in route and navigate the user away from the current screen.
To correct this problem, the slider widget should either revert to direct event binding for the 'click' event or specify that the '_on' method disregard the disabled state of the widget using the 'suppressDisabledCheck' argument.
Alternatively, the slider widget could expose a configurable option to govern whether the widget follows legacy behavior (always intercept and cancel clicks on the <a>) or the new behavior (only intercept clicks on the <a> when the slider is not disabled).
Here are some relevant sections of code to look at:
In UI 1.10.0, ui.slider uses direct event binding:
In 1.10.1, ui.slider delegates to ui.widget._on:
The ui.widgets._on method ignores the click handler callback when the widget is disabled: