React-dnd: Problemas con entradas y áreas de texto dentro del componente arrastrable

Esto se debe al registro del evento selectstart , que aparentemente solo es necesario para la compatibilidad con IE.
Si, como yo, no necesita compatibilidad con IE, aquí está mi solución rápida que puede funcionar para usted:
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed

¡Gracias por informarnos! Me alegra aceptar que un PR solucione esto.

Tengo dos requisitos:

• Todavía necesita tener esa corrección de IE.
• Verifique si preventDefault() es necesario para los otros navegadores. Creo que evita la selección de texto de lo que intentaste arrastrar. Si de hecho ayuda a evitar la selección no deseada en otros navegadores, es posible que desee rodear e.preventDefault() con un cheque a la e.target.tagName !== 'input' (pero uno más inteligente).

Mismo error con <div contentEditable={isEditing} /> .
Además, no puedo editarlo. Ctrl+A y Shift + Arrows no funcionan.

En las próximas tres semanas estaré ocupado y no tengo tiempo para arreglar esto.
Como dije, estoy feliz de aceptar un PR con una solución como se describe en https://github.com/gaearon/react-dnd/issues/178#issuecomment -108110202.

Estaba investigando esto. Si comento todo el cuerpo de la función handleSelectStart , todo funciona como se esperaba. Probé esto en IE11 y parece ser bueno allí también.

@gaearon , ¿sabe si hay un caso de uso específico o una configuración de por qué el evento debe manejarse? IE10? ¿Configuración diferente de textarea / input en un nodo arrastrable? No tengo problemas de selección de texto, y me pregunto si CSS user-select funciona en torno a esto en preventDefault si es necesario.

El problema original era https://github.com/gaearon/react-dnd/issues/128.
Si puede preparar un PR que solucione el problema, pero que también mantenga https://github.com/gaearon/react-dnd/issues/128 funcionando, sería de gran ayuda.

Veré si puedo investigarlo. Necesito encontrar una manera de configurar un caso de prueba simple para IE9.

Creo que el ejemplo de sortable-simple falló en IE9 antes de que se arreglara # 128.

@gaearon Sí, ese fue un buen ejemplo para usar, gracias. Algunas notas:

1. Ningún otro navegador (los últimos Chrome, Safari, FF e IE 11 probados) parecen preocuparse por esto. El evento no necesita ser manejado en absoluto.
2. IE9 solo parece _necesitar_ la llamada e.target.dragDrop() . Se puede deshabilitar la selección de texto creando un controlador que cubra todo el elemento arrastrable, envolviendo el nodo arrastrable en connectDragPreview y el controlador en connectDragSource . Si bien esto puede sonar desagradable, AFAIK no está admitiendo oficialmente IE9, así que ¿es una solución razonable, especialmente cuando es probable que surjan otros problemas en ese navegador?
3. El punto número dos también es útil de todos modos en el caso de que tenga una entrada de texto dentro del arrastrable. Los usuarios no pueden seleccionar texto arrastrando sus ratones si connectDragSource se aplica a todo el nodo (termina arrastrando el nodo en lugar de seleccionar texto), sin embargo, se aplica a un identificador invisible que es del tamaño de todo el nodo funciona muy bien.

No estoy seguro de cómo quiere manejar esto. Sin recurrir a la verificación UA, no sé si hay una excelente manera de lidiar con esto y me parece que está agregando funcionalidad para admitir un navegador compatible no oficial que está rompiendo buenos navegadores que pueden terminar cavando un agujero de mantenimiento. Pero esa es toda mi opinión. Independientemente, hay una solución a este problema que también resuelve otros problemas.

Eliminar el detector de eventos para selectstart hace que contentEditable funcione en Chrome, pero aún no funciona en Safari.

Corregido por https://github.com/gaearon/react-dnd/commit/0a36033693868a7985ea2348105da4fb2cef8a00.

La eliminación del detector de eventos para selectstart hace que contentEditable funcione en Chrome, pero aún no funciona en Safari.

Este es el problema de la API de arrastrar y soltar HTML5 en Safari. No hay nada que podamos hacer al respecto.

La solución para este problema se publicó en [email protected] .
Por favor verifique que funcione.

Confirmado que Ctrl / Cmd-A funciona en <input> dentro de un componente arrastrable.

El intento de seleccionar la entrada o el contenido del área de texto con el panel táctil / mouse comienza a arrastrar el elemento principal

Veo que esto no está solucionado, ¿crear un nuevo problema?

Los elementos con contentEditable establecidos dentro de un contenedor principal que se puede arrastrar no me permitirían seleccionar texto o interactuar con ellos de ninguna manera. Después de investigar un poco, encontré este informe de error: https://bugs.chromium.org/p/chromium/issues/detail?id=170139

Parece que Chrome ha solucionado el problema desde entonces. El comportamiento de Safari se puede arreglar mientras tanto con CSS:

.contenteditable-element {
  user-select: text;
}

@trevorsmith Esto todavía no está arreglando el comportamiento de Firefox. ¿Conoce alguna solución para Firefox?

@ rahul1995 - Acabo de descubrir una solución: simplemente almacene una referencia en el nodo DOM que se puede arrastrar y cuando el usuario se concentre en la entrada / área de texto, establezca el atributo arrastrable en false :

const Test = () => {
  const ref = useRef(null);
  const [focused, setFocused] = useState(false);
  const [_, drag] = useDrag({ item: { type: 'test' } });

  useEffect(() => {
    if (ref.current) {
      ref.current.setAttribute('draggable', !focused);
    }
  }, [focused]);

  return drag(
    <textarea ref={ref} onFocus={() => setFocused(true)} onBlur={() => setFocused(false)}></textarea>
  );
};

Esto debería funcionar para Firefox: wink: