React-dnd: Problèmes avec les entrées et les zones de texte à l'intérieur du composant déplaçable

Cela est dû à l'enregistrement de l'événement selectstart , qui n'est apparemment nécessaire que pour la compatibilité avec IE.
Si, comme moi, vous n'avez pas besoin de la compatibilité IE, voici ma solution rapide qui peut fonctionner pour vous:
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed

Merci d'avoir signalé! Je suis heureux d'accepter un PR corrigeant cela.

J'ai deux exigences:

• Il doit toujours avoir ce correctif IE.
• Veuillez vérifier si preventDefault() est nécessaire pour les autres navigateurs. Je pense que cela empêche la sélection de texte de tout ce que vous avez essayé de faire glisser. Si cela aide effectivement à empêcher une sélection indésirable dans d'autres navigateurs, vous voudrez peut-être entourer e.preventDefault() avec une vérification à la e.target.tagName !== 'input' (mais plus intelligente).

Même bug avec <div contentEditable={isEditing} /> .
Je ne peux pas non plus le modifier. Ctrl+A et Shift + Arrows ne fonctionnent pas.

Dans les trois prochaines semaines, je vais être occupé et je n'ai pas le temps de régler ça.
Comme je l'ai dit, je suis heureux d'accepter un PR avec un correctif comme décrit dans https://github.com/gaearon/react-dnd/issues/178#issuecomment -108110202.

Était à la recherche de cela. Si je commente tout le corps de la fonction handleSelectStart , tout fonctionne comme prévu. Testé cela dans IE11 et semble être bon là aussi.

@gaearon savez-vous s'il existe un cas d'utilisation ou une configuration spécifique expliquant pourquoi l'événement doit être géré du tout? IE10? Configuration différente de textarea / input dans un nœud déplaçable? Je n'ai pas de problèmes de sélection de texte, et je me demande si CSS user-select fonctionne autour de cela sur preventDefault si nécessaire.

Le problème d'origine était https://github.com/gaearon/react-dnd/issues/128.
Si vous pouvez préparer un PR qui résout le problème, mais que https://github.com/gaearon/react-dnd/issues/128 fonctionne également, ce serait d'une grande aide.

Je verrai si je peux me pencher dessus. Besoin de trouver un moyen de mettre en place un cas de test simple pour IE9.

Je pense que l'exemple sortable-simple échoué sur IE9 avant que le # 128 ne soit corrigé.

@gaearon Oui, c'était un bon exemple à utiliser, merci. Quelques notes:

1. Aucun autre navigateur (testé les derniers Chrome, Safari, FF et IE 11) ne semble s'en soucier. L'événement n'a pas besoin d'être géré du tout.
2. IE9 semble seulement _nécessaire_ l'appel e.target.dragDrop() . La désactivation de la sélection de texte peut être effectuée en créant une poignée qui couvre tout le glissé, en enveloppant le nœud déplaçable dans connectDragPreview et la poignée dans connectDragSource . Bien que cela puisse sembler désagréable, AFAIK vous ne supportez pas officiellement IE9, est-ce donc une solution de contournement raisonnable, en particulier lorsque d'autres problèmes sont susceptibles de survenir dans ce navigateur?
3. Le point numéro deux est également utile dans le cas où vous avez une entrée de texte dans le déplaçable. Les utilisateurs ne peuvent pas sélectionner du texte en faisant glisser leur souris si connectDragSource est appliqué à tout le nœud (il finit par faire glisser le nœud au lieu de sélectionner du texte), mais s'applique à une poignée invisible de la taille du nœud entier fonctionne très bien.

Je ne sais pas comment vous voulez gérer cela. Sans recourir à la vérification UA, je ne sais pas s'il existe un excellent moyen de gérer cela et il me semble que cela ajoute des fonctionnalités pour prendre en charge un navigateur pris en charge non officiellement qui brise les bons navigateurs, ce qui peut finir par creuser un trou de maintenance. Mais c'est tout mon avis. Quoi qu'il en soit, il existe une solution de contournement à ce problème qui résout également d'autres problèmes.

La suppression de l'écouteur d'événements pour selectstart fait fonctionner contentEditable dans Chrome, mais cela ne fonctionne toujours pas dans Safari.

Corrigé par https://github.com/gaearon/react-dnd/commit/0a36033693868a7985ea2348105da4fb2cef8a00.

La suppression de l'écouteur d'événements pour selectstart fait que contentEditable fonctionne dans Chrome, mais cela ne fonctionne toujours pas dans Safari.

Il s'agit d'un problème d'API de glisser-déposer HTML5 dans Safari. Nous ne pouvons rien y faire.

Le correctif de ce problème a été publié dans [email protected] .
Veuillez vérifier que cela fonctionne.

Confirmé que Ctrl / Cmd-A fonctionne dans <input> intérieur d'un composant déplaçable.

La tentative de sélection du contenu d'entrée ou de zone de texte avec le pavé tactile / la souris commence à faire glisser l'élément parent

Je vois que ce n'est pas résolu, créer un nouveau problème?

Les éléments dont le contenu est modifiable dans un conteneur parent déplaçable ne me permettraient pas de sélectionner du texte ou d'interagir avec eux de quelque manière que ce soit. Après quelques recherches, j'ai trouvé ce rapport de bogue: https://bugs.chromium.org/p/chromium/issues/detail?id=170139

Il semble que Chrome ait depuis résolu le problème. Le comportement de Safari peut être corrigé entre-temps avec CSS:

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

@trevorsmith Cela ne

@ rahul1995 - Je viens de trouver une solution: il suffit de stocker une référence dans le nœud DOM déplaçable et lorsque l'utilisateur se concentre sur input / textarea, définissez l'attribut draggable sur 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>
  );
};

Cela devrait faire l'affaire pour Firefox: wink: