Inputs inside of sortable items are un selectable.

I'd like to preface this issue by saying thank you for a really great library. I was using html5sortable before, and this library is so much less buggy.

This line in the current version of the library causes any input or textarea inside a Sortable list to be unclickable.

When the mouse button is released, the event is preventDefaulted and the cursor is not placed in the text.

This breaks many content management systems that use sortable items.

Here is a jsfiddle demonstrating the problem.

I have tested the issue you described, and the problem seems to be obsolete in Chrome, is it present in other browsers ?

btw, for inputs and stuff, maybe is better to create move handler (dedicated icon), so input forms remains un-affected by dragging !?

Oh interesting. The problem does not exist in Chrome.
It is most noticeably present in Firefox.

And making a handle may be an appropriate workaround, but the inability to change cursor location in an input is still a bug.

in firefox input gets focus and user can type, in IE.. as usual,

I think a temp. workaround could be - special/separate handler for the input container

The input getting focus is not the problem. Once the input has focus, the
cursor location cannot be changed by a mouse click.

On Mon, Jul 6, 2015 at 8:26 AM, Rodislav Moldovan notifications@github.com
wrote:

in firefox input gets focus and user can type, in IE.. as usual,

I think a temp. workaround could be - special/separate handler for the
input container

—
Reply to this email directly or view it on GitHub
#462 (comment).

This bug is fixed in the dev branch of Sortable.

Take a look at https://jsfiddle.net/ogu8cywg/
I implemented the newest version in script tags

I tested it with Chrome, Mozilla, Safari, MS IE and MS Edge... Issue can be closed

@ChiefORZ

@ChiefORZ Yes.

@ChiefORZ

@ChiefORZ The jsfiddle provided still behaves in a buggy fashion in Firefox 40.0.3.

I want do follow up JoshWillik: Great package (I postponed the sorting feature for years and was impressed how fast this packages solved all the problems I had in mind) - and still a minor issue with text inputs within a sortable DIV in Firefox 41.0.1.

Some more details: I have an outer DIV with multiple DIVs inside that may be sorted. Within each inner DIV there are more inline-block DIVs (cells) and one of them contains a INPUT TYPE="text" (same result if the INPUT is not within a cell-DIV, but directly within the inner DIV). When clicking the text input, it received the focus, but the cursor always jumps the the left-most position (or whereever the cursor has been set with the arrow keys previously). Also, I cannot select text with the mouse cursor.

Tried (a) to give the input a class "nodrag" and set the option filter: ".nodrag" - but then I couldn't focus the text input any more. Tried (b) to attach an onclick-event to the text input that stopped bubbling of the event, but that did not have any visible effect. Of course, I tried the DEV branch from the link above, as well.

Okay ... it seems that problem is: Sortable catches the mousedown event and stops it from bubbling. Here's a workound: In line 285 of the fiddle, linked above, there is a evt.preventDefault(), which is triggered if the filter matches. If this line is removed, the INPUT get a class "nodrag" and set Sortable's option filter: ".nodrag", then editing the text input works in Firefox (also testes in latest IE).

Warning: I do not fully understand, why the mousedown event was catched, here. This may have side-effects, if advanced filtering is used for the Sortable. Maybe, a sufficient bugfix may be skipping the preventDefault() if the event's sender was an INPUT or TEXTAREA.

i also have this issue.. the rows of the table that i told to be disabled in the sorting plugin, now have their select elements somehow faulty, because you can click, but then , it does not open the selector options. Its like something focus out right there. Im using Chrome last?
see this jsbin
http://jsbin.com/joxugoxipu/edit?html,css,js,output

UPDATE
i could eventually fix this, by changing the code, to make


   if (filter) {
          if(!options.handle ){
          evt.preventDefault();  
          }

          return; // cancel dnd
        }

Because when there is handle, then there is no need to prevent default click on the items like selectors etc, like it was calling a preventDefault... so thats why the selector did not worked. But because im using the handle to say what moves or not, i dont have to lock the row selector etc... for that

it works good as you can see in this modified jsbin http://jsbin.com/lekajomoko/edit?html,css,js,output

Hi there.

I'm having the same issue which I fixed by changing the code but I can't really do that anymore.
I'm adding Sortable as an npm package which won't let me change the source code.

Is there a solution that doesn't include editing sortable.js?

This bug still exists on Edge and Firefox, try any jsfiddle link around here and test with the current Sortable.js. In Firefox the cursor can't be set on any position, in Edge you can't do anything inside the textbox

Take a look at preventOnFilter option.

Great, the setting preventOnFilter:false with the appropriate filter:"input" solves the issue. Thanks!

@BurninLeo

I'd like to add in my 2 cents here. This problem still exists today in the latest Chrome and Edge browsers (possibly others as well), and while the above resolution solves it (as mentioned by @BurninLeo), I am unconvinced that my use case below should have needed it to begin with.

My sortableJS list had the following 2 properties set by default:
handle: '.item .drag-handle' and
filter: '.item[data-status=opened]'.

The handle being a simple dragging icon. While the filter is set to prevent dragging from occurring when the list item is in editing mode; that is when a div with a bunch of input fields is appended to the list.

With the above setup, the input fields are not editable (clicking does nothing) on both Chrome and Edge. Removing the filter above or adding preventOnFilter: false solves the problem but why?! I see no reason for this given that I already have a handle (which is a mere icon that does not cover any of the inputs in my list!).

In short, the above resolution should only be needed if there isn't already a handle property but it seems to be needed even when there is already a handle!

Navigation Menu

Repository navigation

Inputs inside of sortable items are un selectable. #462

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Inputs inside of sortable items are un selectable. #462

Description

Activity

rodislav commented on Jul 6, 2015

JoshWillik commented on Jul 6, 2015

rodislav commented on Jul 6, 2015

JoshWillik commented on Jul 6, 2015

ChiefORZ commented on Sep 8, 2015

RubaXa commented on Sep 8, 2015

JoshWillik commented on Sep 8, 2015

BurninLeo commented on Oct 10, 2015

BurninLeo commented on Oct 10, 2015

MiguelQueiroz commented on Sep 4, 2016

WilCodeBoer commented on Sep 12, 2016

isaaclisg commented on Jul 31, 2018

LTBLStudio commented on Jun 4, 2021

BurninLeo commented on Jun 11, 2021

fuad-tareq commented on Mar 11, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions