Material-ui: Рябь остается, если быстро нажать несколько раз

Какой браузер вы используете? Я не могу воспроизвести это в Chrome 59.

Невозможно воспроизвести в:

• Хром 59.0.3071.115
• Firefox 54.0.1
• Край 38.14393.1066.0
• IE 11.1358.14393.0

@oliviertassinari @kgregory Я использую Windows 10, Firefox 54.0.1.
Я использую свой тачпад на своем ноутбуке, чтобы сделать это с большей скоростью двумя пальцами ... Думаю, в этом разница, потому что одним пальцем я не могу это сделать. Это не срочная ошибка, но может произойти.

Я тоже не мог воспроизвести (Windows 10, Firefox 54.0.1), но в Chrome и с правой (дополнительной) кнопкой мыши он ведет себя так.

@NonameSLdev У меня около 9 кликов в секунду, и я не могу воспроизвести это в этой версии Firefox.

@Dattaya , вы постоянно нажимаете правой кнопкой мыши, чтобы воспроизвести это в Chrome?

Nevermind @Dattaya , я воспроизвел в Chrome примерно десять раз

Интересно, а должна ли быть рябь при щелчке правой кнопкой мыши? Я бы сказал нет. Так что, возможно, правильное решение - отключить их.

@oliviertassinari хорошая мысль, но, вероятно, будет какая-то другая комбинация заслуживающих внимания взаимодействий с пользователем, которые приведут к такому поведению. Вы видели что-нибудь в стандартах о ряби чернил при щелчке правой кнопкой мыши (я предполагаю, что там ничего нет)? В Chrome при щелчке правой кнопкой мыши на панели закладок нет ряби. Может, этого достаточно доказательств 😄

Я смотрел на это некоторое время, и я не совсем уверен, почему эта рябь застряла в состоянии TouchRipple (массив ряби).

На 9cps обнаружил кое-что интересное: на firefox рябь не уходит, на chrome уходит крайне медленно. НО, при каждом нажатии на firefox на кнопке, у которой уже есть рябь, которая не оставила другой ряби, появляется, а затем уходит и принимает рябь вместе с ней. Действительно странное поведение

Проблема могла быть исправлена ​​с помощью # 7575. Я бы сказал 50/50, так как мне не удалось воспроизвести

Просто вытащил и переустановил все зависимости, все еще можно воспроизводить, щелкая одновременно левую и правую кнопки мыши в полускоренном темпе.

@kgregory Я думаю, в этом случае проблема на уровне ButtonBase. Спасибо, что попробовали.

Эта проблема сводит меня с ума, что бы я ни старался, я не могу воспроизвести. Я добавил тег good first issue , отлично, если кто-то еще хочет его решить, иначе он останется неразрешенным.

@oliviertassinari Я тестировал его несколько раз. Я могу воспроизвести это только с помощью тачпада моего ноутбука, даже со скоростью 3 кадра в секунду.

Привет, ребята, сначала хорошая работа.
Немного грубо, чтобы идти в ногу с бета-версией, но с каждым днем ​​она становится все круче.

@oliviertassinari, мы используем mui, и у нас есть некоторые странные ошибки, связанные с этой проблемой, возможно, это помогает исправить это: на Mac, используя Chrome, вы не можете воспроизвести эту проблему, и все работает нормально. На машине Linux с хромированными кнопками рябь становится все темнее и темнее, когда вы нажимаете на что-то со скоростью 3 кадра в секунду. Быстрое нажатие не воспроизводит этого. Примечательно то, что включение fastclick https://github.com/ftlabs/fastclick , которое мы используем, исправит это, а кнопки будут правильно обрабатывать события. Нажатие кнопок на странице mui-doc также не имеет этого эффекта, поскольку я предполагаю, что нет библиотек, имеющих какие-либо побочные эффекты на material-ui. Может быть, это поможет воспроизвести или ограничить эту проблему.

Я работаю над приложением Cordova для 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. Насколько я знаю, задержку можно убрать с помощью мета viewport. Подлежит подтверждению.

Я думаю, что это проблема Кордовы (точнее, iOS UIWebView). На самом деле мне не удалось найти SplitMe в магазине приложений, и, к сожалению, у меня нет возможности проверить, загружается ли документация в моем проекте, поскольку CORS отключен, а ссылки HTML на другие домены открываются в Safari (пробовал iframe, не повезло) . Все, что я могу сказать наверняка, это то, что рябь от прикосновения нормально работает на v0.x и накапливается в v1.

В общем, похоже, что все основные браузеры (даже Safari для iOS!) Реализовали исправление с использованием метатега области просмотра, как вы сказали, но оно все еще присутствует в UIWebView, используемом внутри Cordova. Я бы не стал считать Кордову основным браузером / платформой, поэтому я пойму, если это не считается приоритетным вопросом.

Спасибо за быстрый ответ!

@ssalka Вы пробовали https://github.com/apache/cordova-plugin-wkwebview-engine?

Подтверждаю, это намного лучше. Я использую этот плагин на SplitMe .

@NonameSLdev Можете ли вы воспроизвести проблему? За год дело не продвинулось. Думаю, что закрыть будет безопасно.

Да, такое же поведение - рябь остается, и при каждом наведении часть из нее теряет сама себя.

На самом деле это не серьезная проблема, но она существует.

ОБНОВЛЕНИЕ : Подождите. Просто есть идея. Что, если речь идет о большем количестве нажатий (или щелчков) мыши, чем подъемов мыши? Это может произойти из-за использования трекпада, поскольку я использую два пальца для многократного нажатия.

Я только что проверил эту теорию, и она кажется верной: при многократном щелчке мышью, как я, для создания ряби, я получил 21 событие нажатия мыши и всего 11 событий нажатия мыши. Думаю, причина в этом. #TookUsLongEnough

@stavlocker @oliviertassinari Я уже некоторое время сталкиваюсь с этой проблемой. В моем случае я наконец смог отследить его до '-webkit-app-region': 'no-drag' удалив свойство, полностью устранив проблему для меня. Я подозреваю, что это может быть похоже на упомянутую проблему № 11696

К вашему сведению, я использую openfin на chrome 61

@gtsafas . Не глядя на код, я могу сказать, что рябь создается при опускании мыши и удаляется при поднятии мыши, но эта мышь так и не появилась, потому что падений больше, чем подъемов. Ваше исправление хорошее, но оно будет работать только в браузерах webkit.

На мой взгляд, два решения:

• Предлагаю поставить таймер на рябь? Если он не удален через 5 секунд, удалите его автоматически. Что касается UX, то нужно учитывать, что это потенциально может сбить с толку пользователей, которые долго нажимают и видят, что пульсация высвобождается, возможно, заставляя их думать, что они нажали кнопку, отпустив свой щелчок (когда они не отпустили его)?
• Просто создайте рябь при движении мыши вверх, а не вниз. Очевидно, это выглядело бы иначе, и если пользователь будет удерживать кнопку, он не увидит ряби, но это исправляет.

@stavlocker да, я не предлагал это как исправление. Но я говорил, что другая проблема, которая вызывает это, - перетаскивание изображений. Для меня это были не изображения, а то, что взаимодействует с перетаскиванием. Что-то мешало появлению mouseup. По крайней мере, в моем случае это не было связано с пользователями с разной скоростью нажатия, это происходило для всех, пока там был этот css.

Мы можем установить таймер или указатель мыши, но это просто скрывает проблему. Я думаю, нам нужно знать, почему mouse up не запускается, прежде чем исправлять его.

Такое случается с вами на всех сайтах с материальным интерфейсом?

@gtsafas Это интересно. Но это не ошибка MUI, когда курсор мыши не запускается. В моем случае это потому, что с помощью трекпада я могу щелкать двумя пальцами. Я думаю, что, поскольку я использую два пальца, которые могут запускать другую мышь, когда один из них уже нажат, иногда я поднимаю другой палец, когда нажат второй, который трекпад не распознает как мышь вверх, потому что что-то нажато. Это вызывает больше падений, чем подъемов, поэтому рябь остается.

@stavlocker хорошо, тогда это другое. Пытаясь отладить это (до того, как я понял, что это -webkit-app-region), я добавил ведение журнала вокруг мыши вниз / вверх и также наблюдал больше падений, чем взлетов.

Значит, если подключить обычную мышь, она работает нормально?

@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 Мы должны предотвратить инвариант по умолчанию. Что-то может быть не так.

@kgregory @oliviertassinari
Я не уверен, что это правильно, но вот что я обнаружил после небольшого тестирования:
Каким-то образом это происходит, когда щелчок мыши странным образом взаимодействует с контекстным меню. Я протестировал это, не сохранив пульсацию с помощью: 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. Если вы можете воспроизвести проблему с последней версией, сообщите нам!

@oliviertassinari @kgregory Я все еще могу воспроизвести, как я уже сказал на # 13740. Этот PR устраняет только спам контекстного меню, но не спам трекпада. Этот комментарий описывает проблему, от которой я страдаю, и предлагает два решения.

Способы воспроизведения:

1. Перейти к демонстрации компонентов кнопки
2. Используйте трекпад, чтобы нажать кнопку несколько раз

Я использую Lenovo Yoga 700 под управлением Windows 10, могу воспроизводить в Chrome 71, Firefox 64 (Quantum), Edge 42.

Я уверен, что это может быть воспроизведено на разных компьютерах, поскольку проблема в том, что трекпад регистрирует несколько пальцев и иногда не регистрирует столько же подъемов мыши, сколько опусканий мыши, как я пришел к выводу в своем предыдущем тестировании .

Я вижу кумулятивное затенение пульсаций кнопок в моем телефонном промежутке, приложение React mui на iPad. на Android и в Интернете проблем нет. Каждый раз, когда я нажимаю кнопку, он становится темнее (или светлее), пока не станет насыщенным.

Я также могу подтвердить эту проблему в Safari / iOS - это даже не требует быстрого нажатия, наложение темного / светлого просто никогда не исчезает после нажатия.

@oliviertassinari @kgregory Я все еще могу воспроизвести, как я уже сказал на # 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.

Я уверен, что это может быть воспроизведено на разных компьютерах, поскольку проблема в том, что трекпад регистрирует несколько пальцев и иногда не регистрирует столько же подъемов мыши, сколько опусканий мыши, как я пришел к выводу в своем предыдущем тестировании .

Если проблема в том, что срабатывает больше событий mousedown, чем mouseup, мы должны посмотреть, есть ли соответствующее количество mouseup за пределами этого элемента. Один трюк для таких вещей: вы можете добавить обработчик движения мыши (который удалит сам себя) к корневому элементу DOM при опускании мыши, тогда указатель мыши всегда будет срабатывать, независимо от того, где был захвачен mousedown. Я подозреваю, что всегда есть какое-то событие, которое запускает очистку, но его может не быть в исходном элементе.

@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- - это может иметь какое-то отношение? На самом деле я не совсем уверен, как material-ui применяет префиксы (autoprefixer) - есть ли на это документы?

Это может помочь:
https://material-ui.com/getting-started/supported-platforms/#css -prefixing

Я также сталкиваюсь с этой проблемой в своей собственной среде с использованием Meteor, React и Material-UI и только на iOS. Я смог использовать эмулятор устройства Chrome и только для того, чтобы эта ошибка срабатывала при эмуляции устройств iOS, а не устройств Android.
Я пока не могу воспроизвести это с демонстрационными песочницами, но это может быть связано с компонентом ButtonBase, потому что я вижу проблему с кнопками и вкладками.

Теперь я вижу это даже в Chrome в Windows с включенным мобильным режимом в Dev Tools. В этом приложении: https://www.pixstoriplus.com/

@CaptainN Я посмотрю позже. Просто для наглядности вы можете опубликовать свои шаги воспроизведения. Какой Chrome вы используете?

Раньше он делал это довольно последовательно, но теперь, когда я пытаюсь воспроизвести это в Chrome, ничего. Что-то должно было привести его в какое-то состояние ошибки.

В iOS вы можете просто загрузить это приложение и довольно легко увидеть проблему. Для простейшего примера нажимайте вперед и назад между кнопками «Домой» и «Поиск» в нижней части навигации. Или нажмите «Поиск», затем вернитесь на главную и нажмите «Домой» несколько раз.

Я могу воссоздать его на iOS в нижней части навигации.

Мне удалось добиться более последовательного поведения, если вы перезагрузите страницу после переключения из обычного Chrome в режим устройства.

@ zuus-keith Если это связано с мобильным симулятором chrome dev tool, мы не должны особо это исправлять. Разве это не та же основная причина?

@oliviertassinari Я считаю, что это та же

Вдобавок, до сих пор о проблеме сообщалось только в 3 разных случаях, но все они использовали один и тот же стек технологий (например, Meteor, React и MUI).

Оказалось, что это произошло из-за другого очень распространенного пакета Meteor, называемого «fastclick», который на самом деле не был необходим (если вы используете правильные настройки области просмотра) в Safari в течение многих лет. Если кто-то столкнется с этой проблемой, решение - просто удалить "fastclick".

Есть ли кто-нибудь, на кого это влияет, а не в смоделированной среде? Или это нормально закрыть?

Это было исправлено для меня в не смоделированных средах (на iPad) путем удаления пакета fastclick из моего приложения Meteor.

На данный момент закрытие, если кто-то может воспроизвести, дайте нам знать.