React-dnd: ドラッグ可能なコンポーネント内の入力とテキスト領域の問題

作成日 2015年06月02日  ·  17コメント  ·  ソース: react-dnd/react-dnd

ドラッグ可能なコンポーネント内に<input> <textarea>要素と

  1. cmd+AまたはCtrl+Aショートカットは、入力またはテキスト領域では機能しません(ただし、 Shift + Arrowsテキストを選択しても機能します)
  2. タッチパッド/マウスで入力またはテキストエリアのコンテンツを選択しようとすると、親要素のドラッグが開始されます

ドラッグ可能なコンポーネントは次のようになります。

draggable component

bug

最も参考になるコメント

ドラッグ可能な親コンテナ内にcontentEditableが設定されている要素では、テキストを選択したり、それらを操作したりすることはできません。 少し掘り下げた後、私はこのバグレポートを見つけました: https

その後、Chromeで問題が修正されたようです。 それまでの間、Safariの動作はCSSで修正できます。

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

全てのコメント17件

これは、 selectstartイベントの登録が原因で発生します。これは、IEの互換性のためにのみ必要とされるようです。
私のようにIEとの互換性が必要ない場合は、次のように簡単に修正できます。
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed

報告してくれてありがとう! これを修正するPRを受け入れてうれしいです。

2つの要件があります。

  • それでもIEを修正する必要があります。
  • 他のブラウザにpreventDefault()が必要かどうかを確認してください。 ドラッグしようとしたものをテキストで選択できなくなると思います。 それが実際に他のブラウザでの不要な選択を防ぐのに役立つ場合は、 e.preventDefault()e.target.tagName !== 'input'チェックで囲むことをお勧めします(ただし、よりスマートなものです)。

<div contentEditable={isEditing} />と同じバグ。
また、編集できません。 Ctrl+AShift + Arrowsは機能しません。

次の3週間で私は忙しくなり、これを修正する時間がありません。
私が言ったように、 https: //github.com/gaearon/react-dnd/issues/178#issuecomment-108110202で説明されているように修正されたPRを受け入れてうれしいです。

これを調べていました。 handleSelectStart関数の本体全体をコメントアウトすると、すべてが期待どおりに

@gaearonイベントを処理する必要がある理由について、特定のユースケースまたは設定があるかどうかを知っていますか? IE10? ドラッグ可能なノードのtextarea / inputは異なる設定ですか? テキスト選択の問題は発生しません。必要に応じて、CSS user-selectpreventDefault超えてこれを回避できるかどうか疑問に思います。

元の問題はhttps://github.com/gaearon/react-dnd/issues/128でした。
問題を修正するだけでなく、 https://github.com/gaearon/react-dnd/issues/128を機能させ続けるPRを準備できれば、それは大きな助けになります。

私がそれを調べることができるかどうかを確認します。 IE9の簡単なテストケースを設定する方法を理解する必要があります。

#128が修正される前に、IE9でsortable-simple例が失敗したと思います。

@gaearonええ、それは使用する良い例でした、ありがとう。 いくつかの注意:

  1. 他のブラウザ(最新のChrome、Safari、FF、IE 11でテスト済み)はこれを気にしていないようです。 イベントを処理する必要はありません。
  2. IE9は、 e.target.dragDrop()呼び出しのみが_必要_であるように見えます。 テキスト選択を無効にするには、ドラッグ可能なノード全体をカバーするハンドルを作成し、ドラッグ可能なノードをconnectDragPreviewでラップし、ハンドルをconnectDragSourceでラップします。 これは厄介に聞こえるかもしれませんが、IE9を公式にサポートしていないので、特にそのブラウザで他の問題が発生する可能性がある場合は、合理的な回避策ですか?
  3. ポイント2は、ドラッグ可能な範囲内にテキスト入力がある場合にも役立ちます。 connectDragSourceがノード全体に適用されている場合(テキストを選択する代わりにノードをドラッグすることになります)、ユーザーはマウスをドラッグしてテキストを選択できませんが、ノード全体のサイズである非表示のハンドルに適用されます非常にうまく機能します。

これをどのように処理したいかわからない。 UAチェックに頼らずに、これに対処するための優れた方法があるかどうかはわかりません。非公式にサポートされているブラウザーをサポートする機能が追加されているように見えます。 しかし、それが私の意見です。 とにかく、他の問題も解決するこの問題の回避策があります。

selectstartのイベントリスナーを削除すると、ChromeではcontentEditable機能しますが、Safariでは機能しません。

https://github.com/gaearon/react-dnd/commit/0a36033693868a7985ea2348105da4fb2cef8a00で修正されました

selectstartのイベントリスナーを削除すると、contentEditableはChromeで機能しますが、Safariでは機能しません。

これは、SafariでのHTML5ドラッグアンドドロップAPIの問題です。 それについて私たちにできることは何もありません。

この問題の修正は[email protected]リリースされました。
動作することを確認してください。

Ctrl / Cmd-Aがドラッグ可能なコンポーネント内の<input>機能することを確認しました。

タッチパッド/マウスで入力またはテキストエリアのコンテンツを選択しようとすると、親要素のドラッグが開始されます

これは修正されていないようですが、新しい問題を作成しますか?

ドラッグ可能な親コンテナ内にcontentEditableが設定されている要素では、テキストを選択したり、それらを操作したりすることはできません。 少し掘り下げた後、私はこのバグレポートを見つけました: https

その後、Chromeで問題が修正されたようです。 それまでの間、Safariの動作はCSSで修正できます。

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

@trevorsmithこれはまだFirefoxの動作を修正していません。 Firefoxの回避策を知っていますか?

@ rahul1995-解決策を見つけました。ドラッグ可能なDOMノードへの参照を保存し、ユーザーが入力/テキスト領域にフォーカスしたときに、ドラッグ可能な属性を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>
  );
};

これはFirefoxのトリックを行うはずです:wink:

このページは役に立ちましたか?
0 / 5 - 0 評価