React-dnd: مشاكل في المدخلات ومناطق النص داخل المكون القابل للسحب

يحدث هذا بسبب تسجيل الحدث selectstart ، والذي يبدو أنه مطلوب فقط للتوافق مع IE.
إذا كنت مثلي لا تحتاج إلى توافق مع IE ، فإليك الحل السريع الذي قد يناسبك:
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed

شكرا على الإبلاغ! أنا سعيد لقبول العلاقات العامة لإصلاح هذا.

لدي متطلبان:

• لا يزال بحاجة إلى إصلاح IE.
• يرجى التحقق مما إذا كانت هناك حاجة إلى preventDefault() للمتصفحات الأخرى. أعتقد أنه يمنع اختيار النص لأي شيء حاولت سحبه. إذا كان هذا يساعد بالفعل في منع التحديد غير المرغوب فيه في المتصفحات الأخرى ، فقد ترغب في إحاطة e.preventDefault() ببعض الشيكات la e.target.tagName !== 'input' (لكن أكثر ذكاءً).

نفس الخطأ مع <div contentEditable={isEditing} /> .
كما لا يمكنني تحريره. Ctrl+A و Shift + Arrows .

في الأسابيع الثلاثة المقبلة سأكون مشغولاً وليس لدي الوقت لإصلاح هذا.
كما قلت ، يسعدني قبول العلاقات العامة مع الإصلاح كما هو موضح في https://github.com/gaearon/react-dnd/issues/178#issuecomment -108110202.

كان يبحث في هذا. إذا علقت على جسم الوظيفة handleSelectStart بالكامل ، فسيعمل كل شيء كما هو متوقع. اختبرت هذا في IE11 ويبدو أنها جيدة هناك أيضًا.

gaearon هل تعرف ما إذا كانت هناك حالة استخدام أو إعداد محدد لماذا يجب التعامل مع الحدث على الإطلاق؟ IE10؟ إعداد مختلف عن textarea / input في عقدة قابلة للسحب؟ لا أحصل على مشكلات في تحديد النص ، وأتساءل عما إذا كان CSS user-select يعمل حول هذا الأمر على preventDefault إذا لزم الأمر.

كان الإصدار الأصلي https://github.com/gaearon/react-dnd/issues/128.
إذا كان بإمكانك إعداد PR الذي يعمل على حل المشكلة ، ولكن أيضًا يحافظ على https://github.com/gaearon/react-dnd/issues/128 ، فسيكون ذلك بمثابة مساعدة كبيرة.

سوف أرى ما إذا كان بإمكاني النظر في الأمر. تحتاج إلى اكتشاف طريقة لإعداد حالة اختبار بسيطة لـ IE9.

أعتقد أن sortable-simple example فشل في IE9 قبل إصلاح # 128.

gaearon نعم كان هذا مثالًا جيدًا للاستخدام ، شكرًا. بعض الملاحظات:

1. لا يبدو أن أي متصفحات أخرى (تم اختبارها لأحدث إصدارات Chrome و Safari و FF و IE 11) تهتم بهذا الأمر. لا يحتاج الحدث إلى التعامل معه على الإطلاق.
2. يبدو أن IE9 فقط _Need_ e.target.dragDrop() المكالمة. يمكن تعطيل تحديد النص من خلال إنشاء مقبض يغطي كامل المساحة القابلة للسحب ، ولف العقدة القابلة للسحب في connectDragPreview والمقبض في connectDragSource . على الرغم من أن هذا قد يبدو سيئًا ، إلا أن AFAIK أنت لا تدعم IE9 رسميًا ، فهل هذا حل بديل معقول ، خاصة عندما يحتمل ظهور مشكلات أخرى في هذا المتصفح؟
3. تعد النقطة الثانية مفيدة أيضًا على أي حال في حالة وجود إدخال نص داخل أداة السحب. لا يمكن للمستخدمين تحديد النص عن طريق سحب الفئران الخاصة بهم إذا تم تطبيق connectDragSource العقدة بأكملها (ينتهي الأمر بسحب العقدة بدلاً من تحديد النص) ، ومع ذلك يتم تطبيقها على مقبض غير مرئي بحجم العقدة بأكملها يعمل بشكل جيد جدا.

غير متأكد كيف تريد التعامل مع هذا. بدون اللجوء إلى فحص UA ، لا أعرف أن هناك طريقة رائعة للتعامل مع هذا ويبدو لي أنها تضيف وظائف لدعم متصفح مدعوم بشكل غير رسمي والذي يكسر المتصفحات الجيدة والذي قد ينتهي به الأمر إلى حفر ثغرة صيانة لكن هذا كل رأيي. بغض النظر ، هناك حل بديل لهذه المشكلة يحل أيضًا مشكلات أخرى.

تؤدي إزالة مستمع الحدث لـ selectstart جعل contentEditable يعمل في Chrome ، لكنه لا يزال لا يعمل في Safari.

تم الإصلاح بواسطة https://github.com/gaearon/react-dnd/commit/0a36033693868a7985ea2348105da4fb2cef8a00.

تؤدي إزالة مستمع الحدث إلى selectstart إلى جعل المحتوى قابلاً للتعديل في Chrome ، ولكنه لا يزال لا يعمل في Safari.

هذه هي مشكلة سحب وإفلات HTML5 API في Safari. لا شيء يمكننا القيام به حيال ذلك.

تم إصدار الإصلاح لهذه المشكلة في [email protected] .
يرجى التحقق من أنه يعمل.

تم التأكيد على أن Ctrl / Cmd-A يعمل في <input> داخل مكون قابل للسحب.

تبدأ محاولة تحديد الإدخال أو محتوى منطقة النص باستخدام لوحة اللمس / الماوس في سحب العنصر الأصل

أرى أن هذا لم يتم إصلاحه ، هل تريد إنشاء مشكلة جديدة؟

لن تسمح لي العناصر ذات المحتوى القابل للتعديل داخل حاوية أصل قابلة للسحب بتحديد نص أو التفاعل معها بأي شكل من الأشكال. بعد بعض البحث ، وجدت تقرير الخطأ هذا: https://bugs.chromium.org/p/chromium/issues/detail؟

يبدو أن Chrome قد أصلح المشكلة منذ ذلك الحين. يمكن إصلاح سلوك Safari في الوقت الحالي باستخدام CSS:

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

trevorsmith هذا ما زال لا يصلح سلوك Firefox. هل تعرف أي حل بديل لفايرفوكس؟

@ rahul1995 - لقد اكتشفت للتو حلاً: ما عليك سوى تخزين المرجع إلى عقدة DOM القابلة للسحب وعندما يركز المستخدم على الإدخال / textarea ، اضبط سمة السحب على 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: