jQuery UI

Bug appear in Firefox browser. Not in Chrome nor IE. (Didn't test other browsers). Once you use some jquery sortable functions: $( "#sortable" ).sortable(); $( "#sortable" ).disableSelection(); on html elements like (i.e. td or li) The css ... [More] active (also focus?) will stop having an effect from now on (as if it's not there). So if you have a sortable li (like in site example) and a css command: li:active{ background-color: green; cursor: n-resize; } and u use $( "li" ).sortable(); The css above will stop working. As seen in this fiddle:  http://jsfiddle.net/9pqywyxm/3/ In fiddle when you try to change li position: In Chrome background will become green as the active css specifies. In Firefox nothing will happen to background- as the active css is ignored. I recommend trying in chrome and Firefox to see the difference. Thank you. If you have any questions feel free to email me: rokosongs@… [Less]

Can be reproduced on the official examples:  http://jqueryui.com/autocomplete/#maxheight Using IE8, 9, 10 or 11 and autocomplete: Getting so few results that no scrollbar appears, if you mouseover the last result, a scrollbar appears. It's only ... [More] over the last result, not any before it. This does not happen in Chrome. Example to search for is "an". Mousing over "Erlang" does nothing, while mousing over "Fortan" adds a scrollbar [Less]

I try to make sortable nested containers but I have an issue with the jQuery UI Sortable plugin and I can not find a suitable solution. You can try here :  http://jsfiddle.net/cmruser/ycafdu0r/ Drag the nested drop container out side container and ... [More] the ui-sortable-placeholder is not show. You should have the following javascript error : Uncaught HierarchyRequestError: Failed to execute 'insertBefore' on 'Node': The new child element contains the parent. attached is image of the error:  http://i58.tinypic.com/334nfxf.jpg Have you an idea of the problem? Do you have a solution? Is it a bug? Thanks! [Less]

A much more accurate description of the problem then is that tabs do not receive focus on click when they're sortable. They keyboard functionality isn't broken at all. This is actually intentional behavior for all interactions: we prevent click ... [More] events when interacting with the element (e.g., when sorting). I'm not sure that we'll change that in any way, but it's certainly something to consider. More likely, we'll just change the demo to force focus on sort. [Less]

fixed: Release: Publish to npm Fixes #11101 Changeset: ab0bb87634c19a47211d9e46afc0c09fbf49ee29

worksforme: I'm not seeing that. I do see that if you sort the currently focused tab, it loses focus, but the keyboard functionality continues to work fine once a tab is focused again.

Adding either sortable or draggable to a tabs widget disables the keyboard functionality. This is easy to see using the example of tabs with sortable on the jQueryUI site. You can't use the keyboard to move between tabs and all accessibility is ... [More] disabled. It's easy to modify this example to show that the same phenomena occurs for draggable. I understand that sortable and draggable are not considered accessible and have no keyboard controls. However, I should be able to add them to a tabs widget without defeating the keyboard controls that are there normally. I currently can't add sortable as an option for sighted users without killing any functionality for screenreader users. [Less]

fixed: Widget: Call ._setOptionDisabled() on init if the widget is disabled Fixes #9151 Ref gh-1599 Changeset: 7dde5c9d75148cdca7cf86ff0c6e310fdc5a4054

duplicate: Duplicate of #6844.Nothing has changed.