Material-ui: يبقى الريبل في حالة النقر المتعدد بسرعة

تم إنشاؤها على ٢٥ يوليو ٢٠١٧  ·  56تعليقات  ·  مصدر: mui-org/material-ui

إذا نقر شخص ما بما يزيد عن 9 نقرات في الثانية لفترة قصيرة (1-2 ثانية) ، فإن التموجات لا تترك الزر ويظل مع اللون. مظاهرة صغيرة:

نرحب بتجربتها بنفسك: https://material-ui.com/demos/buttons/#text -buttons

تحرير: يصف هذا التعليق المشكلة - هناك المزيد من حالات الماوس لأسفل أكثر من الصعود ولم يتم تحرير التموج.

bug 🐛 ButtonBase

التعليق الأكثر فائدة


نعم ، نفس السلوك - التموج يبقى وفي كل مرة يفقد بعضه نفسه.

إنها ليست مشكلة كبيرة حقًا ، لكنها موجودة.

تحديث : انتظر. حصلت للتو على فكرة. ماذا لو كان هذا يتعلق بالمزيد من عمليات النقر بالماوس أكثر من عمليات الماوس؟ لأن استخدام لوحة التتبع يمكن أن يحدث لأنني أستخدم إصبعين للضغط بشكل متكرر.

لقد اختبرت هذه النظرية للتو ويبدو أنها صحيحة: عندما أقوم بالنقر المتعدد مثلما أفعل لإنشاء التموج ، حصلت على 21 حدثًا للماوس و 11 حدثًا فقط. أعتقد أن هذا هو السبب. #TookUsLongEnough

ال 56 كومينتر

ما المتصفح الذي تستخدمه؟ لا يمكنني إعادة إنتاجه باستخدام Chrome 59.

غير قادر على التكاثر في:

  • كروم 59.0.3071.115
  • Firefox 54.0.1
  • الحافة 38.14393.1066.0
  • IE 11.1358.14393.0

oliviertassinarikgregory أنا على ويندوز 10، فايرفوكس 54.0.1.
أنا أستخدم لوحة اللمس الخاصة بي على الكمبيوتر المحمول الخاص بي للقيام بذلك بسرعة أكبر بكلتا الأصابع ... أعتقد أن هذا هو الاختلاف لأنني بإصبع واحد لا يمكنني القيام بذلك. إنه ليس خطأ عاجلاً ولكنه قد يحدث.

لم أتمكن من إعادة إنتاج أي منهما (Windows 10 ، Firefox 54.0.1) ولكن في Chrome وباستخدام زر الماوس الأيمن (الثانوي) ، فإنه يتصرف هكذا.

NonameSLdev لدي حوالي 9 نقرات في الثانية ولا يمكنني إعادة إنتاجها في هذا الإصدار من Firefox.

Dattaya هل تنقر مرارًا وتكرارًا بالزر الأيمن للفأرة لإعادة إنتاج هذا في Chrome؟

NevermindDattaya ، لقد تم إعادة إنتاجي في Chrome عن طريق النقر شبه السريع على زر الماوس الأيمن والأيسر في وقت واحد حوالي عشر مرات.

أنا أتساءل هل يجب أن نحصل على تموج عند النقر بزر الماوس الأيمن؟ أود أن أقول لا. لذلك ربما يكون الإصلاح الصحيح هو تعطيلها.

oliviertassinari حسن التفكير ، ولكن من المحتمل أن يكون هناك مزيج آخر من تفاعلات المستخدم الجديرة

لقد نظرت إلى هذا لفترة قصيرة ولست متأكدًا تمامًا من سبب تقطعت السبل بهذه التموجات في حالة TouchRipple (مجموعة تموج).

في 9cps وجدت شيئًا مثيرًا للاهتمام: في Firefox ، لا تترك التموجات ، على الكروم تغادر ببطء شديد. ولكن ، عند كل نقرة على Firefox على زر به بالفعل تموجات لم تترك تموجًا آخر ، يظهر ثم يترك ويأخذ تموجًا معه. سلوك غريب بالفعل

ربما تم إصلاح المشكلة بواسطة # 7575. أود أن أقول 50/50 لأنني لم أتمكن من التكاثر

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

kgregory أعتقد أنها مشكلة على مستوى ButtonBase في هذه الحالة. شكرا لمحاولتك الخارجيه.

هذه المشكلة تدفعني للجنون ، بغض النظر عما أحاول ، لا يمكنني التكاثر. لقد أضفت علامة good first issue ، إذا أراد شخص آخر معالجتها ، فهذا رائع ، وإلا فسيظل بدون حل.

oliviertassinari لقد اختبرت ذلك حول عدد قليل. يمكنني إعادة إنتاجه فقط باستخدام لوحة اللمس بجهاز الكمبيوتر المحمول ، حتى بمعدل 3 سنتات في الثانية.

مرحبا شباب ، في البداية ، عمل جيد.
من الصعب بعض الشيء مواكبة الإصدار التجريبي ، لكنها تزداد روعة على أساس يومي.

oliviertassinari نحن نستخدم mui an لدينا بعض الأخطاء الغريبة المتعلقة بهذه المشكلة ، ربما يساعد ذلك في إصلاح هذا: على جهاز Mac ، لا يمكنك إعادة إنتاج هذه المشكلة باستخدام الكروم وكل شيء يعمل بشكل جيد. على جهاز Linux ، مع الكروم ، تصبح الأزرار المموجة أغمق وأكثر قتامة عند النقر فوقها عند 3cps. النقر فوقه بسرعة لا يعيد إنتاج هذا. اللافت للنظر أن تحويل fastclick https://github.com/ftlabs/fastclick ، الذي نستخدمه ، سوف يصلح هذا ، وستتعامل الأزرار مع الأحداث بشكل صحيح. الضغط على الأزرار الموجودة في صفحة mui-doc ليس له هذا التأثير أيضًا ، كما أفترض ، لا توجد مكتبات لها أي آثار جانبية على واجهة المستخدم المادية. ربما يساعد في إعادة إنتاج أو تحديد هذه المشكلة.

أنا أعمل على تطبيق كوردوفا iOS (مع FastClick لتجنب تأخير material-ui @ next (1.0 v23) وأحصل على نفس السلوك. يبدو أن إزالة FastClick يعمل على إصلاح تموجات اللمس المتراكمة ، ولكنه يؤدي إلى ضعف UX بسبب التأخير البالغ 300 مللي ثانية.

oliviertassinari لقد لاحظت أن لديك تطبيقًا يسمى SplitMe يستخدم material-ui @ next + cordova ، هل تعرف طريقة لتجنب هذا الخطأ المموج باللمس عند استخدامه جنبًا إلى جنب مع FastClick؟ أم أن SplitMe لديها أيضًا تأخير 300 مللي ثانية؟

PS قبل أن أستخدم [email protected] مع FastClick ولم أواجه أي مشاكل في تموج اللمس

أم أن SplitMe لديها أيضًا تأخير 300 مللي ثانية؟

ssalka هل يمكنك ملاحظة التأخير في التوثيق؟ هل هي قضية خاصة بقرطبة؟ لم أكن أقوم بالكثير من العمل على SplitMe لفترة طويلة. بقدر ما أعرف ، يمكن إزالة التأخير باستخدام meta viewport. ليتم تأكيده.

أعتقد أنها مشكلة كوردوفا (بشكل أكثر تحديدًا ، iOS UIWebView). لم أتمكن في الواقع من العثور على SplitMe في متجر التطبيقات ، وللأسف ليس لدي طريقة للتحقق مما إذا كان يتم تحميل الوثائق في مشروعي ، حيث تم تعطيل CORS وفتح روابط HTML إلى المجالات الأخرى في Safari (جرب إطار iframe ، ولم يحالفني الحظ) . كل ما يمكنني قوله على وجه اليقين هو أن تموجات اللمس تعمل بشكل جيد على الإصدار v0.x وتتراكم في الإصدار 1.

بشكل عام ، يبدو أن جميع المتصفحات الرئيسية (حتى Safari لنظام iOS!) قد نفذت إصلاحًا باستخدام علامة viewport meta ، كما قلت ، لكنها لا تزال موجودة في UIWebView المستخدمة داخليًا بواسطة Cordova. ومع ذلك ، لن أعتبر كوردوفا متصفحًا / نظامًا أساسيًا رئيسيًا ، لذلك سأتفهم ما إذا كان هذا لا يعتبر مسألة ذات أولوية.

شكرا على الاستجابة السريعة!

NonameSLdev هل لا يزال بإمكانك إعادة


نعم ، نفس السلوك - التموج يبقى وفي كل مرة يفقد بعضه نفسه.

إنها ليست مشكلة كبيرة حقًا ، لكنها موجودة.

تحديث : انتظر. حصلت للتو على فكرة. ماذا لو كان هذا يتعلق بالمزيد من عمليات النقر بالماوس أكثر من عمليات الماوس؟ لأن استخدام لوحة التتبع يمكن أن يحدث لأنني أستخدم إصبعين للضغط بشكل متكرر.

لقد اختبرت هذه النظرية للتو ويبدو أنها صحيحة: عندما أقوم بالنقر المتعدد مثلما أفعل لإنشاء التموج ، حصلت على 21 حدثًا للماوس و 11 حدثًا فقط. أعتقد أن هذا هو السبب. #TookUsLongEnough

stavlockeroliviertassinari إيف تم تواجه هذه المسألة لحظة الآن. بالنسبة لحالتي ، تمكنت أخيرًا من تعقبها وصولاً إلى '-webkit-app-region': 'no-drag' إزالة الخاصية إلى حل المشكلة تمامًا بالنسبة لي. أظن أن هذا قد يكون مشابهًا للمشكلة المشار إليها رقم 11696

فقط لمعلوماتك أنا أستخدم openfin على الكروم 61

gtsafas ربما يمكن أن يصلح هذا الأمر ، لكن كما قلت في تعليقي (فوق تعليقي) ، يرجع السبب في ذلك إلى وجود المزيد من الفأرة لأسفل أكثر من الصعود. بدون النظر إلى الكود ، يمكنني القول أن التموج يتم إنشاؤه على الماوس لأسفل وإزالته عند الماوس لأعلى - لكن هذا الفأر لأعلى لم يصل أبدًا لأن هناك المزيد من الانخفاضات أكثر من الصعود. إصلاحك جيد ولكنه سيعمل فقط في متصفحات webkit.

حلان كما أراه:

  • أقترح أن نضع مؤقتًا على التموجات؟ إذا لم تتم إزالته بعد 5 ثوانٍ ، فقم بإزالته تلقائيًا. من ناحية UX ، يجب أن يؤخذ في الاعتبار أن هذا قد يربك المستخدمين الذين يضغطون لفترة طويلة ويشاهدون التموج قد تم إصداره ، وربما يجعلهم يعتقدون أنهم ضغطوا على الزر من خلال إطلاق نقرةهم (عندما لم يقوموا بتحريرها)؟
  • فقط قم بإنشاء تموج على الماوس بدلاً من الماوس لأسفل. من الواضح أن هذا سيبدو مختلفًا وإذا كان المستخدم يحمل زرًا فلن يرى تموجًا ولكنه يعمل على إصلاح هذا.

stavlocker نعم لم أكن أقترحه

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

هل يحدث هذا لك في كل مواقع واجهة المستخدم المادية؟

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

stavlocker حسنًا فهذا مختلف. أثناء محاولة تصحيح هذا (قبل أن أدرك أنه كان -webkit-app-area) ، أضفت تسجيلًا حول الماوس لأسفل / لأعلى ولاحظت أيضًا المزيد من الانخفاضات أكثر من الصعود.

لذا ، إذا قمت بتوصيل الماوس العادي فإنه يعمل بشكل جيد؟

gtsafas يمكنك إعادة إنتاج السلوك بالماوس عن طريق النقر في نفس الوقت على الزرين الأيمن والأيسر.

كانت لدينا هذه المشكلة أيضا. من المحتمل أنك تمنع بعض أحداث الماوس الأخرى ... تحقق من الكود الخاص بك لشيء مثل:

document.addEventListener("mousedown", myScript); // should be document.addEventListener("mousedown", myScript, false);
document.addEventListener("mouseup", myScript); // should be document.addEventListener("mouseup", myScript, false);

//jquery example: 
        // (...)
        documentElement.on({
            'mouseup': (e) => {
                e.preventDefault(); // WRONG! cut this off
                isDrag = false
            },
        // (...)
        });

ejnu يجب علينا منع الثابت الافتراضي. قد يكون هناك خطأ ما.

تضمين التغريدة
لست متأكدًا مما إذا كان هذا صحيحًا ولكن هذا ما وجدته بعد اختبار بسيط:
يحدث هذا بطريقة ما عندما تتفاعل نقرة مع قائمة السياق بطريقة غريبة. لقد اختبرت هذا من خلال الفشل في استمرار التموج مع: onContextMenu={e => {e.preventDefault()}} على ButtonBase. لا يبدو أنه يمكنك اكتشاف حدوث نقرة في قائمة السياق ، لكنني أعتقد أنني تمكنت من إصلاح ذلك عن طريق إيقاف التموج في حدث قائمة السياق: # 13740

   handleTouchMove = createRippleHandler(this, 'TouchMove', 'stop');

+  handleContextMenu = createRippleHandler(this, 'ContextMenu', 'stop');

   handleBlur = createRippleHandler(this, 'Blur', 'stop', () => {
    clearTimeout(this.focusVisibleTimeout);
    if (this.state.focusVisible) {


        onTouchEnd={this.handleTouchEnd}
        onTouchMove={this.handleTouchMove}
        onTouchStart={this.handleTouchStart}
+       onContextMenu={this.handleContextMenu}
        ref={buttonRef}
        tabIndex={disabled ? '-1' : tabIndex}
        {...buttonProps}

يمكن لأي شخص أن يؤكد؟

قام @ 0maxxam0 بتمويل هذه المشكلة بمبلغ 40 دولارًا. شاهده على IssueHunt

يجب حلها بـ # 13740. إذا كان بإمكانك إعادة إظهار المشكلة بأحدث إصدار ، فأخبرنا بذلك!

oliviertassinarikgregory أستطيع الإنجاب، كما سبق أن قلت في # 13740. هذا PR يعمل فقط على إصلاح البريد العشوائي في قائمة السياق ، ولكن ليس البريد العشوائي في لوحة التتبع. يصف هذا التعليق المشكلة التي أعاني منها ويقدم حلين.

طرق التكاثر:

  1. انتقل إلى العروض التوضيحية لمكون الزر
  2. استخدم لوحة التعقب الخاصة بك للنقر فوق الزر عدة مرات

أنا أستخدم Lenovo Yoga 700 الذي يعمل بنظام التشغيل Windows 10 ، ويمكن إعادة إنتاجه في Chrome 71 و Firefox 64 (Quantum) و Edge 42.

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

أرى تظليلًا تموجيًا تراكميًا للأزرار في الهاتف ، وتفاعل مع تطبيق mui على جهاز iPad. على Android و Web لا توجد مشكلة. في كل مرة أنقر فيها على الزر يصبح أغمق (أو أفتح) حتى يتشبع.

يمكنني تأكيد هذه المشكلة على Safari / iOS أيضًا - لا يستغرق الأمر حتى النقر بسرعة ، فالغطاء المظلم / الفاتح لا يختفي أبدًا بعد النقر عليه.

oliviertassinarikgregory أستطيع الإنجاب، كما سبق أن قلت في # 13740. هذا PR يعمل فقط على إصلاح البريد العشوائي في قائمة السياق ، ولكن ليس البريد العشوائي في لوحة التتبع. يصف هذا التعليق المشكلة التي أعاني منها ويقدم حلين.

طرق التكاثر:

1. Go to the [button component demos](https://material-ui.com/demos/buttons/)

2. Use your trackpad to click the button a bunch of times

أنا أستخدم Lenovo Yoga 700 الذي يعمل بنظام التشغيل Windows 10 ، ويمكن إعادة إنتاجه في Chrome 71 و Firefox 64 (Quantum) و Edge 42.

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

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

CaptainN ما هو iOS / Safari الذي تقوم بإعادة إنتاج هذا عليه. لا يمكنني إعادة الإنشاء على iOS 12.1.2

iOS 11.3.1 - أراه في الغالب على مكونات IconButton ، ولكن أيضًا على Fab.

يبدو أنه من المفترض أن:

  1. حرك الدائرة من نقطة اللمس.
  2. تتلاشى (ألفا) أثناء الرسوم المتحركة.
  3. أفترض أنه تمت إزالتها وتنظيفها بعد اكتمال الرسوم المتحركة.

الخطوتان 2 و 3 بالنسبة لي لا تحدثان على جهاز iPad (11.3.1) على جهاز iPhone أقدم (11.4.1) أو iPhone 8 (12.1.2).

سأرى ما إذا كان بإمكاني البحث في الكود في وقت ما ، لكن لا يمكنني تقديم أي وعود بشأن التوقيت.

CaptainN هل هذا في العروض التوضيحية للمستندات ، أم في التعليمات البرمجية الخاصة بك؟ لا يمكنني إعادة إنتاجه باستخدام المستندات على جهاز iPhone 10 يعمل بنظام iOS 12.1 ، أو جهاز iPad أقدم مع 12.1.3 ، لذلك أتساءل عما إذا كانت هناك عوامل مربكة في اللعب؟

لا نقول أنه ليس خطأ ، ولكن قد يكون هناك المزيد من الخطوات المطلوبة لإعادة إنتاجه.

إنه في تطبيقي الخاص ، وهو تطبيق متوسط ​​الحجم تم إنشاؤه باستخدام Meteor و React و Material-UI. سيكون متاحًا للجميع قريبًا ، لذا يمكنني مشاركة الرابط.

سأبحث عن السبب في الكود في وقت ما ، وإذا لم أتمكن من العثور عليه ، فحاول إجراء تخفيض.

أنا أيضًا أستخدم SSR - أحصل على بعض التحذيرات حول سمات نمط غير متطابقة ، وعادة ما لا يتفق الخادم أو العميل على بادئة -webkit- - هل يمكن أن يكون لهذا الأمر شيئًا ما؟ لست متأكدًا حقًا من كيفية تطبيق واجهة المستخدم المادية للبادئات (المصفف التلقائي) - هل توجد مستندات حول ذلك؟

أواجه هذه المشكلة أيضًا في بيئتي الخاصة باستخدام Meteor و React و Material-UI وفقط على iOS. لقد تمكنت من استخدام محاكي جهاز Chrome وفقط لتشغيل هذا الخطأ عند محاكاة أجهزة iOS وليس أجهزة Android.
لا يمكنني نسخ هذا الأمر مع صناديق الحماية التجريبية حتى الآن ، ولكن قد ينشأ من مكون ButtonBase لأنني أرى مشكلة الأزرار وعلامات التبويب.

أرى هذا الآن حتى في Chrome على Windows مع تمكين وضع الهاتف المحمول في أدوات التطوير. في هذا التطبيق: https://www.pixstoriplus.com/

CaptainN سآخذ نظرة لاحقا. فقط من أجل الوضوح ، يمكنك نشر خطوات الاستنساخ الخاصة بك. ما هو Chrome الذي تستخدمه؟

لقد كان يفعل ذلك باستمرار من قبل ، ولكن الآن بعد أن أحاول إعادة إنتاجه في Chrome ، لا شيء. يجب أن يكون هناك شيء ما قد وضعه في حالة خطأ من نوع ما.

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

يمكنني إعادة إنشائه على نظام iOS في شريط التنقل السفلي.

تمكنت من الحصول على سلوك أكثر اتساقًا إذا أعدت تحميل الصفحة بعد التبديل من Chrome العادي إلى وضع الجهاز.

@ zuus-keith إذا كان متعلقًا بمحاكاة الجوال لأداة chrome dev ، فهذا ليس شيئًا يجب علينا إصلاحه بشكل خاص. ما لم يكن هو نفس السبب الجذري؟

oliviertassinari أعتقد أنه نفس السبب الجذري. لقد صادفته في البداية على جهاز iOS حقيقي ، ويحدث أن جهاز محاكاة الهاتف المحمول لأداة chrome dev التي تم ضبطها على طرق عرض "iPhone" أو "iPad" تنتج نفس السلوك.

للإضافة ، لم يتم الإبلاغ عن المشكلة حتى الآن إلا في 3 حالات مختلفة ولكن جميعها تستخدم نفس المكدس الفني (مثل Meteor و React و MUI).

تبين أن هذا يرجع إلى حزمة Meteor شائعة جدًا تسمى "fastclick" - والتي لم تكن ضرورية حقًا (إذا كنت تستخدم إعدادات منفذ العرض الصحيحة) في Safari لسنوات. إذا حدث أي شخص عبر هذه المشكلة ، فإن الحل هو ببساطة إزالة "fastclick".

هل هناك من يتأثر بهذا وليس في بيئة محاكاة؟ أم أنه من المقبول إغلاق هذا؟

تم إصلاح هذا بالنسبة لي في البيئات غير المحاكاة (على iPad) عن طريق إزالة حزمة fastclick من تطبيق meteor الخاص بي.

إغلاق الآن ، إذا كان بإمكان أي شخص أن يتكاثر ، أخبرنا بذلك.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

ghost picture ghost  ·  3تعليقات

revskill10 picture revskill10  ·  3تعليقات

mb-copart picture mb-copart  ·  3تعليقات

chris-hinds picture chris-hinds  ·  3تعليقات

FranBran picture FranBran  ·  3تعليقات