ドラッグ可能なコンポーネント内に<input>
<textarea>
要素と
cmd+A
またはCtrl+A
ショートカットは、入力またはテキスト領域では機能しません(ただし、 Shift + Arrows
テキストを選択しても機能します)ドラッグ可能なコンポーネントは次のようになります。
これは、 selectstart
イベントの登録が原因で発生します。これは、IEの互換性のためにのみ必要とされるようです。
私のようにIEとの互換性が必要ない場合は、次のように簡単に修正できます。
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed
報告してくれてありがとう! これを修正するPRを受け入れてうれしいです。
2つの要件があります。
preventDefault()
が必要かどうかを確認してください。 ドラッグしようとしたものをテキストで選択できなくなると思います。 それが実際に他のブラウザでの不要な選択を防ぐのに役立つ場合は、 e.preventDefault()
をe.target.tagName !== 'input'
チェックで囲むことをお勧めします(ただし、よりスマートなものです)。<div contentEditable={isEditing} />
と同じバグ。
また、編集できません。 Ctrl+A
とShift + Arrows
は機能しません。
次の3週間で私は忙しくなり、これを修正する時間がありません。
私が言ったように、 https: //github.com/gaearon/react-dnd/issues/178#issuecomment-108110202で説明されているように修正されたPRを受け入れてうれしいです。
これを調べていました。 handleSelectStart
関数の本体全体をコメントアウトすると、すべてが期待どおりに
@gaearonイベントを処理する必要がある理由について、特定のユースケースまたは設定があるかどうかを知っていますか? IE10? ドラッグ可能なノードのtextarea
/ input
は異なる設定ですか? テキスト選択の問題は発生しません。必要に応じて、CSS user-select
がpreventDefault
超えてこれを回避できるかどうか疑問に思います。
元の問題はhttps://github.com/gaearon/react-dnd/issues/128でした。
問題を修正するだけでなく、 https://github.com/gaearon/react-dnd/issues/128を機能させ続けるPRを準備できれば、それは大きな助けになります。
私がそれを調べることができるかどうかを確認します。 IE9の簡単なテストケースを設定する方法を理解する必要があります。
#128が修正される前に、IE9でsortable-simple
例が失敗したと思います。
@gaearonええ、それは使用する良い例でした、ありがとう。 いくつかの注意:
e.target.dragDrop()
呼び出しのみが_必要_であるように見えます。 テキスト選択を無効にするには、ドラッグ可能なノード全体をカバーするハンドルを作成し、ドラッグ可能なノードをconnectDragPreview
でラップし、ハンドルをconnectDragSource
でラップします。 これは厄介に聞こえるかもしれませんが、IE9を公式にサポートしていないので、特にそのブラウザで他の問題が発生する可能性がある場合は、合理的な回避策ですか?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:
最も参考になるコメント
ドラッグ可能な親コンテナ内にcontentEditableが設定されている要素では、テキストを選択したり、それらを操作したりすることはできません。 少し掘り下げた後、私はこのバグレポートを見つけました: https :
その後、Chromeで問題が修正されたようです。 それまでの間、Safariの動作はCSSで修正できます。