Artikel

Nicht jede Warnung in deinem Projekt stammt aus deinem eigenen Code.

1 Min. Lesezeit

Vor ein paar Tagen sah ich ständig diese Warnung in der Konsole: „Unable to preventDefault inside passive event listener invocation.“

Ein Ereignis passiert das offene Tor eines Listeners, während ein mit einem Warndreieck markiertes Drittanbietermodul außerhalb der gestrichelten Codegrenze mit einem blockierten Abbruchpfad verbunden ist.

Ich arbeitete an einem Stories-Feature im Instagram-Stil: Bilder, Videos, Tap-Navigation und Halten zum Pausieren. Das Feature funktionierte einwandfrei, aber die Warnung erschien fast bei jedem Tap auf dem Handy.

Mein erster Gedanke war naheliegend: Wo habe ich Mist gebaut? Ich prüfte den Stack Trace, und das Problem lag gar nicht in meinem Code. Es kam von react-insta-stories: Die Bibliothek rief e.preventDefault() direkt in einem Touch-Event auf.

Das Problem: Das Event lief über einen passiven Listener und war damit nicht immer abbrechbar. Deshalb gab der Browser die Warnung immer wieder aus. Der Fix war simpel: if (e.cancelable) e.preventDefault();. Eine Zeile, und die Warnung war weg, ohne das Verhalten zu ändern.

Meine wichtigste Erkenntnis: Nicht jede Warnung in deinem Projekt stammt aus dem Code, den du geschrieben hast. Manchmal kann dir das sorgfältige Lesen des Stack Trace ersparen, stundenlang das Falsche zu reparieren. Ich habe das Problem upstream gemeldet, weil die Wahrscheinlichkeit groß ist, dass ein anderer Entwickler auf genau dasselbe Problem stößt.

Originalveröffentlichung (externe Website)

Artikel teilen