BBC-Navigationsleisten-Komponente fiel je nach externem Monitor aus

(joshtumath.uk)

1 Punkte von GN⁺ 2024-11-19 | 1 Kommentare | Auf WhatsApp teilen

Auf der BBC-UK-Website schlug die Klickverarbeitung des More-Buttons nur in einer bestimmten Homeoffice-Umgebung fehl; ein scheinbar gewöhnlicher UI-Bug entpuppte sich als Problem mit dem Koordinatensystem bei mehreren Monitoren
Wenn ein externer Monitor oberhalb und links des Hauptmonitors platziert war, konnten screenX und screenY in click-Events von Chrome und Firefox negativ werden
Der vorhandene Code erkannte einen Pointer-Klick mit event.screenX > 0 || event.screenY > 0 und stufte daher Klicks mit negativen Koordinaten nicht als Mausklicks ein
Die Korrektur war simpel: Es wurde nicht mehr geprüft, ob screenX und screenY größer als 0 sind, sondern ob sie nicht 0 sind; daraus wurde event.type === 'click' && (event.screenX!== 0 || event.screenY!== 0)
Selbst mit Unit-Tests, Puppeteer, manuellen Tests und Tests mit assistiven Technologien können solche Bugs wegen Unklarheiten in der UI-Events-Spezifikation und Annahmen über Koordinaten bei mehreren Monitoren übrig bleiben

BBC-Navigationsbug, der nur in einer bestimmten Umgebung reproduzierbar war

Die Navigationsleiste der BBC-UK-Website öffnet ein Menü, wenn Nutzer den More-Button aktivieren
Dieser Button verwendet ein click-Event; dieses Event kann nicht nur durch die Maus, sondern auch durch Touch sowie über Enter und Space auf der Tastatur ausgelöst werden
Ein Teammitglied hatte das Problem nur, wenn es seinen Arbeits-Laptop zu Hause verwendete; derselbe Laptop funktionierte im Büro normal
Auch zu Hause trat der Fehler nur auf, wenn das Browserfenster auf dem externen Monitor lag; auf dem Laptop-Display funktionierte der Button normal
Wenn das Problem auftrat, öffnete der JavaScript-Handler nicht das Menü, sondern das Menü wurde über das no-JavaScript fallback-Verhalten geöffnet
In Safari trat dasselbe Problem nicht auf

Die Reproduktionsbedingung war die Monitorposition

Das Team grenzte die Reproduktionsbedingungen ein, indem es prüfte, welche Faktoren in der häuslichen Umgebung das Problem auslösten
Der externe Monitor war oberhalb des Laptop-Bildschirms angeordnet; wenn diese Anordnung in den OS-Einstellungen geändert wurde, verschwand das Problem
Auch ein anderes Teammitglied konnte den Bug reproduzieren, nachdem es die Monitoranordnung im Betriebssystem entsprechend eingestellt hatte
Zu Beginn der Untersuchung wurden zwei Bedingungen festgestellt
- In Safari trat das Problem nicht auf
- Das Problem trat auf, wenn sich der externe Monitor oberhalb und links des Hauptmonitors befand

Negative Koordinaten bei `screenX` und `screenY`

Als das click-Event des More-Buttons per console.log geprüft wurde, waren die Werte von screenX und screenY in Chrome und Firefox negativ
Ein click-Event ist unabhängig von der auslösenden Eingabe eine Art PointerEvent, daher enthält das Event-Objekt Informationen über den Maus- oder Touch-Pointer, der den Klick ausgelöst hat
screenX und screenY geben die Koordinaten der angeklickten Stelle auf dem Bildschirm in Pixeln an
In der DOM UI Events spec waren keine konkreten Informationen dazu zu finden, ob diese Eigenschaften negativ sein können
Der Unterschied zwischen Safari und Chrome/Firefox zeigt, dass Browser bei Multi-Monitor-Konfigurationen unterschiedliche Darstellungen von Bildschirmkoordinaten verwenden können
Dieses Interoperabilitätsproblem wurde dem WebKit-Team gemeldet

Unterschiede zwischen Browsern bei Multi-Monitor-Koordinaten

Bei Multi-Monitor-Konfigurationen behandelt das Bildschirmkoordinatensystem des Browsers mehrere Monitore wie eine einzige große Fläche
Bei zwei horizontal angeordneten 800px-Monitoren kann der x-Koordinatenbereich beispielsweise von 0 bis 1600 reichen
In Safari scheint der Koordinatenbereich immer als positiver Bereich beim Monitor ganz links oben zu beginnen
In Chrome und Firefox scheinen die Koordinaten relativ zum Hauptmonitor berechnet zu werden; auf Bildschirmen oberhalb oder links des Hauptmonitors können daher negative Koordinaten auftreten
Dieser Bug trat nur auf, wenn screenX und screenY negativ waren

Der tatsächliche fehlerhafte Code und die Korrektur

Im fehlerhaften Code prüfte isInvokedByMouse, ob ein click-Event durch einen Maus- oder Touch-Pointer ausgelöst wurde, indem geprüft wurde, ob screenX oder screenY positiv sind

const isInvokedByMouse = event => event.screenX > 0 || event.screenY > 0;
const isInvokedByKeyboard = event => isEnterKey(event) || isSpaceKey(event);

// ...

const toggleMenu = event => {
  // ...

  if (isInvokedByMouse(event) || isInvokedByKeyboard(event)) {
    event.preventDefault();

    // Do stuff to open the menu and move the focus...
  }
};

Dieser Code ging davon aus, dass screenX und screenY eines durch einen Pointer ausgelösten click-Events positiv sind
Wenn Nutzer den More-Button auf einem Monitor mit negativen Bildschirmkoordinaten anklickten, erkannte der Event-Handler den Klick nicht an, und es wurde auf das Standardverhalten des More-Links zurückgefallen
Die Korrektur bestand darin, statt zu prüfen, ob screenX und screenY größer als 0 sind, zu prüfen, ob sie nicht 0 sind

const isInvokedByMouse = event =>
  event.type === 'click' && (event.screenX !== 0 || event.screenY !== 0);

Durch diese Änderung können auch Nutzer mit ungewöhnlichen Multi-Monitor-Anordnungen die Navigationsleiste der BBC-Website verwenden

Verbleibende Designprobleme und anschließendes Refactoring

Die Korrektur selbst war einfach, aber im Code blieben weiterhin merkwürdige Stellen zurück
Es ist nicht nötig zu prüfen, ob ein click durch die Maus oder die Tastatur ausgelöst wurde, und der Event-Handler ist dadurch komplexer geworden, dass er auch keydown-Events verarbeitet
Man muss vorsichtig damit sein, welche Annahmen man über das Verhalten von APIs trifft; außerdem trug die unklare Spezifikation dazu, ob screenX und screenY negativ sein können, dazu bei, das Problem zu verdecken
Dieser Code hatte Unit-Tests, Puppeteer-Tests sowie manuelle Tests mit mehreren Browsern, Geräten und assistiven Technologien durchlaufen, aber der Bug wurde nicht entdeckt
Laut Korrektur vom 19. November 2024 wurde die Navigationskomponente später refaktoriert, und auch der Event-Handler des menu-Buttons wurde stark verändert
Ein Folgebeitrag beantwortet Fragen zur Art des Refactorings und häufig gestellte Fragen: How I refactored the BBC navigation bar and a follow-up FAQ

1 Kommentare

GN⁺ 2024-11-19

Hacker-News-Kommentare

Zur Ergänzung für alle, die nicht bis zum WebKit-Bugreport geklickt haben: Ein WebKit-Entwickler fragte die BBC, warum es nützlich sei, erkennen zu können, ob ein Event von der Tastatur kam, und der Autor antwortete, dass Interoperabilität wegen von Anwendungsfällen im Bereich Barrierefreiheit nötig sei.
Der Menü-Button der Navigationsleiste auf der BBC-Website in Großbritannien verhält sich etwas unterschiedlich, je nachdem, ob er mit einem Zeiger oder mit der Tastatur geöffnet wird. Ein Klick-Event öffnet immer das Menü, aber wenn es per Zeiger geöffnet wird, wandert der Fokus zum Menü-Container, und wenn es per Tastatur geöffnet wird, wandert der Fokus ohne Menü-Öffnungsanimation zum ersten Link im Menü. Das click-Event ist geräteunabhängig und daher gut geeignet, wenn man eine Benutzererfahrung für Tastaturnutzer bauen will; auf der Tastatur wird es nur durch Space oder Enter ausgelöst. Wenn man keydown verwendet, muss man selbst prüfen, ob es Space/Enter ist.
Quelle: https://bugs.webkit.org/show_bug.cgi?id=281430
- Interessant ist, dass eine naive englische Lesart von Code und Beschreibung im WebKit-Bug nicht zur tatsächlichen Struktur des Codes passt. Der relevante Code ist const isInvokedByMouse = event => event.screenX > 0 || event.screenY > 0; und const isInvokedByKeyboard = event => isEnterKey(event) || isSpaceKey(event);; oberflächlich wirkt es so, als wolle man Events entweder als Maus oder als Tastatur klassifizieren.
  Tatsächlich entstehen aber vier Kategorien: Maus und nicht Tastatur, Tastatur und nicht Maus, beides, keines von beidem. Wie beim ursprünglichen Bug wird „keines von beidem“ unpassend behandelt, und es ist fraglich, ob „beides“ korrekt funktioniert. Der Code sollte bewusst damit umgehen, dass Tastatur und Maus getrennte Boolesche Werte sind, oder so aufgebaut sein, dass eventSource einander ausschließende Kategorien wie "keyboard", "mouse", "not sure" zurückgibt
- Das scheint mir kein Bug zu sein. Der erste Fehler der Entwickler war der Versuch, für Tastatur und Maus unterschiedliche Benutzererfahrungen zu schaffen.
  Es ist besser, sich am Standardverhalten zu orientieren und eine Komponente zu entwerfen, die in beiden Anwendungsfällen funktioniert. Bei Barrierefreiheit sollte man nicht versuchen, zu clever zu sein. Am Ende wurde es eine Lösung, die fast schon ein Hack ist, und solche Ansätze brechen zwangsläufig oder erzeugen Nebenwirkungen. Gute Möglichkeiten, im Kontext von Barrierefreiheit unterschiedlich zu behandeln, sind selten, weil dieser Bereich von vornherein nicht dafür gedacht ist, unterschiedlich behandelt zu werden
- Dieser Artikel wirkt verwirrend. Ich verstehe es so, dass die BBC je nach Maus-„Klick“ oder Tastatur-„Klick“ ein leicht unterschiedliches Verhalten möchte und bei der Tastatur den Fokus ohne Animation auf den ersten Link im Menü setzen will.
  Gleichzeitig wollen sie die Bequemlichkeit, nur an ein einziges Event zu binden. click ermöglicht das, aber es gibt keine Möglichkeit festzustellen, ob das Event durch einen Mausklick oder durch Tastatureingabe entstanden ist, deshalb verwenden sie in Chrome die instabile Heuristik, dass eine Mausposition von screenX=0, screenY=0 entweder ein Klick am Ursprung oder ein Tastatur-Trigger sei. Aus Sicht von jemandem, der schon an Accessibility-Projekten gearbeitet hat, ist das eine ziemlich schlechte Idee; wenn ich das in einem PR gesehen hätte, hätte ich um ein Rewrite gebeten. Ideal wäre es zwar, wenn Browser sich gleich verhielten, aber das eigentliche Problem scheint zu sein, dass screenX und screenY bei einem per Tastatur erzeugten click fast bedeutungslos sind.
  Im Idealfall würde statt eines MouseEvent ein allgemeineres Event emittiert, das sowohl für Tastatur als auch Maus gilt, etwa "trigger", und Informationen über die Trigger-Quelle liefert. Da das in der aktuellen Spezifikation nicht existiert und man sofort eine Lösung braucht, wäre es viel robuster und weniger hacky, zusätzlich an keydown zu binden und dann, wenn auf demselben Element zusammen mit keydown ein click auftritt, es als Tastatureingabe zu behandeln
- Ich verstehe, warum der Autor screenX und screenY braucht, aber ich frage mich weiterhin, warum screenX echte Bildschirmkoordinaten zurückgeben muss statt einer Position innerhalb des Renderers oder der gerenderten Seite wie layerX, layerY.
  Der Bedarf des Autors ließe sich auch mit Renderer-Positionen erfüllen, ohne die Position des Browserfensters an jede besuchte Website preiszugeben
- Bei „wenn das Menü geöffnet wird, wollen wir nicht, dass sich Fokus- und Animationsverhalten je nachdem leicht unterscheiden, ob der Benutzer mit dem Zeiger oder mit der Tastatur ‚geklickt‘ hat“ ist don’t vielleicht einfach ein Tippfehler, der die Bedeutung ins Gegenteil verkehrt
Bei der Stelle „Man musste isInvokedByMouse nur so ändern, dass nicht mehr geprüft wird, ob screenX und screenY größer als 0 sind, sondern nur noch, ob sie ungleich 0 sind“ frage ich mich, was in dem extrem seltenen Fall passiert, dass ein Nutzer tatsächlich an Position 0,0 mit der Maus klickt.
Ich kenne mich mit JS nicht gut aus, aber ist eine Prüfung auf != 0 wirklich die beste oder einzige Methode? Beim erneuten Lesen scheint der Satz, dass der Event-Handler auch keydown verarbeitet und deshalb komplex ist und später stärker refaktoriert werden müsse, die aktuelle Änderung aber vorerst ausreiche, diesen Punkt teilweise abzudecken
- Das Abfragen der Bildschirmposition wirkt wie eine Heuristik, um den Charakter des Events zu bestimmen. Intuitiv würde man eher instanceof MouseEvent verwenden, aber auch das wirkt riskant oder hacky.
  Ich frage mich, warum man sich auf so eine Heuristik stützt. Vielleicht wird toggleMenu von mehreren Event-Handlern verwendet, oder es gibt andere Besonderheiten dieser Codebasis. Ohne das Gesamtbild ist das schwer zu beurteilen. Die Antwort scheint hier zu stehen: https://news.ycombinator.com/item?id=42174177
- Im korrigierten Code wird bereits event.name == 'click' geprüft. Warum man dann einige legitime Klick-Events herausfiltern will, verstehe ich nicht
- Doch. Man kann Media-Queries dazu verwenden, festzustellen, ob das primäre Eingabegerät ein Zeigegerät ist und sogar, ob es ein Gerät mit hoher Genauigkeit ist, und danach filtern.
  Ich habe das früher verwendet, um auszuwählen, welches Layout angezeigt werden soll. Wenn man nur auf Touch-Eingabe hören möchte, kann man das so machen und dann im Event preventDefault aufrufen, damit der Browser anschließend kein click-Event erzeugt. Oder man spart sich einfach die Mühe und schreibt direkt einen Click-Handler
Es ist lobenswert, dass die BBC bei Investitionen in Barrierefreiheit auf einen unangenehmen Bug gestoßen ist. Aber warum schafft es die Branche bis heute nicht, ein Dropdown zu bauen, das sich für alle Nutzer konsistent öffnet?
Ist Barrierefreiheit wirklich so schwer? Hätte die BBC dafür ein Web-Framework oder eine Web-Component verwenden sollen, die so etwas bereits abdeckt? Als Full-Stack-Entwickler mit Backend-Schwerpunkt fasse ich Browser-Komponenten nur ungern an. Im Verhalten gibt es viele subtile Details, und Implementierungen sind über lange Zeit erprobt worden. Zum Beispiel wirkt es wie ein leichtes Scheitern, wenn man ein eigenes Textfeld baut, ohne das Verhalten von Textfeldern auf verschiedenen Plattformen gründlich untersucht zu haben. Selbst auf Websites großer Unternehmen sehe ich oft kaputtes Copy-and-Paste und verschluckte Zeichen. Warum Textfelder im Jahr 2024 kaputt sind, verstehe ich nicht, und React wirkt auf mich inzwischen überheblich
Ich persönlich hätte wohl auf serverseitige Templates, ein CSS-Framework wie Bulma und minimales JS gesetzt. Für Websites, die ein glattpoliertes Custom Branding verlangen, ist das nicht ideal, aber Textfelder funktionieren dann ordentlich und die Entwicklungskosten bleiben überschaubar. Ob das die Barrierefreiheitsanforderungen der BBC erfüllt, weiß ich allerdings nicht sicher
- Ich kenne nicht auf alle Fragen die Antwort, aber auf „Ist Barrierefreiheit wirklich so schwer?“ kann ich ganz klar mit ja antworten
  Ein konkretes Beispiel sind Modals. Wenn man nicht sehbehindert ist, sieht man ein weißes Kästchen mit UI-Komponenten darüber und einen grauen Bereich, den man „nicht anfassen“ soll. Mit einem Screenreader gibt es keine Garantie, dass man diese Information bekommt. Wenn man per Tab durch die UI-Elemente geht und wieder oben im Kasten ankommt, kündigt ein bestimmter Screenreader das an? Listet er die verfügbaren interaktiven Elemente auf? In derselben Reihenfolge wie ein anderer Screenreader? Wie ist es auf dem Handy, wie auf dem Mac? Melden Screenreader und Browser die Eingabeelemente korrekt, oder lassen sie den Nutzer stillschweigend aus dem Modal heraus und zurück in den Rest der Website gelangen?
  Bei Barrierefreiheit kann man nicht darauf vertrauen, dass Betriebssystem, Browser und Screenreader zusammenarbeiten oder sich im passenden Kontext vernünftig verhalten. 2019 musste ich einen Bug in VoiceOver + Safari melden, bei dem negative CSS-Margins dazu führten, dass ein Screenreader einen RTL-Textblock in umgekehrter Reihenfolge vorlas. Visuell stand dort 9/10/2019, aber im Screenreader hörte es sich wie „ten slash nine slash two-thousand-and-nineteen“ an, und als Workaround mussten wir den Text mit aria-hidden ausblenden und danach ein unsichtbares p-Tag mit der richtigen Reihenfolge einfügen. Wenn man also merkwürdigen Accessibility-Code sieht, gibt es manchmal wirklich keinen besseren Weg. Selbst wenn man die gesamte Codebasis umkrempelt und Barrierefreiheit zur obersten Priorität macht, kann ein Update von JAWS oder VoiceOver alles auf schwer nachvollziehbare Weise kaputt machen
- Stimme zu. Viele Probleme entstehen allerdings letztlich dadurch, dass User-Agents solche Elemente auf sehr fragwürdige Weise anpassen
  Meistens ist das in Ordnung, aber es gibt einen Grund, warum reset.css-Dateien existieren, und hier scheint man möglicherweise einen noch extremeren Ansatz gewählt zu haben, um solche Probleme vollständig zu umgehen. Ich versuche gerade nachzuvollziehen, wie sie zu dieser Entscheidung gekommen sind
Das wirkt wie ein selbst verursachter Bug, der aus einer falschen Heuristik entstanden ist. Man hat angenommen, positive screenX/Y-Werte bedeuteten ein Mausereignis, und wegen unzureichendem Tracking/Logging wurde die Untersuchung zusätzlich erschwert
Statt die passendere Eigenschaft pointerType zu prüfen, die andere Kommentare vorgeschlagen haben, überrascht mich etwas, dass die Lösung des Autors darin besteht, noch mehr wackelige Heuristik obendraufzusetzen. So nach dem Motto, aus den letzten zwei Indizien abzuleiten, dass man bei screenX- und screenY-Koordinaten nicht nur positive, sondern auch negative Werte prüfen müsse
- Tatsächlich ist genau das geplant. Wir werden bald Code mergen, der pointerId === -1 verwendet und danach auf screenX === 0 zurückfällt
  Als dieser Code vor etwa vier Jahren ursprünglich geschrieben wurde, verwendeten noch nicht alle Browser für click ein PointerEvent
Ich verstehe schon grundsätzlich nicht, warum eine Website überhaupt die Mausposition im Bildschirmkoordinatensystem bekommen kann
- Ich habe nach Gründen gesucht, aber nicht viel gefunden. Dass eine Website die Browserfensterposition über window.screenX/window.screenY kennen und Klickpositionen in diesem Koordinatensystem gemeldet bekommen kann, klingt auf dem Desktop eigentlich unsinnig
  Der TOR Browser scheint screenX und screenY zu verschleiern, um Fingerprinting zu vermeiden. Ich frage mich, ob jemand je einen guten Anwendungsfall für diese Funktion gesehen hat. Mir fallen nur Anwendungen mit zwei Fenstern ein, die miteinander interagieren, oder Websites, deren Verhalten von der Position auf einem virtuellen Bildschirm abhängt
- Das ist nützlich, wenn man Spiele baut, deren Grafik aus mehreren kleinen Browserfenstern besteht, die miteinander interagieren
  Beispiel: https://youtu.be/3al8prbfK5o?si=loNtyqIfMFkppm5V
- Weil es in den 10 Tagen, die 1995 für die Entwicklung von JavaScript vorgesehen waren, leicht zu implementieren war, und danach einfach Abwärtskompatibilität passiert ist :(
- Wenn man auf Klick-Events reagiert, möchte man vielleicht die Koordinaten der Klickposition kennen. Vor allem bei Click-and-Drag-Aktionen nutzt man sie, um zwischen Events Deltas zu berechnen und damit die Position des gezogenen Objekts zu aktualisieren
  Warum man die Koordinaten prüft, statt event.type anzusehen, verstehe ich allerdings nicht. Trotzdem ist der Beitrag selbst ein schönes Rätsel, und ich kann mich gut in dieses Gefühl hineinversetzen, auf Code zu schauen, den ich nicht geschrieben habe, und zu fragen: „Warum ist es wichtig, dass Klickkoordinaten nicht 0 sind?“, „Warum prüfen wir nicht einfach, ob event.target der Button ist, den wir aktivieren wollen?“, „Warum verwenden wir JavaScript, obwohl details/summary dasselbe leisten könnte?“
- Wird für CAPTCHAs ohne JavaScript verwendet. Funktioniert gut und sendet beim Klicken nur x und y des Mausklicks
Warum wird überhaupt nach Bildschirmkoordinaten gefiltert? Was ist, wenn der Nutzer ein alternatives Eingabegerät ohne Bildschirm verwendet?
Das click-Event allein ist schon ein ausreichendes Signal dafür, dass der Nutzer das Menü aktivieren wollte. Ich verstehe nicht, warum man das Rad neu erfindet
- Laut Artikel sollte isInvokedByMouse prüfen, ob ein click-Event durch Maus oder Touch-Pointer und nicht durch die Tastatur ausgelöst wurde, indem kontrolliert wurde, ob screenX- oder screenY-Koordinaten positiv sind
  Man wollte also Tastaturaktivierung von Mausaktivierung unterscheiden, und der Autor hat dabei offenbar angenommen, dass Bildschirmkoordinaten bei Mausereignissen immer positiv seien
Ich habe noch einen Blogbeitrag veröffentlicht, um den Kontext zu erklären, der die Leute interessiert hat, und Fragen zu beantworten. Darin erkläre ich, warum ich von Anfang an screenX === 0 geprüft habe, warum ich für Tastatur- und Mauseingaben ein unterschiedliches Verhalten wollte und wie ich refaktoriert habe, um weitere Zwischenfälle zu verhindern.
Hoffentlich ist das hilfreich: https://www.joshtumath.uk/posts/2024-11-18-how-i-refactored-...
Was ist der richtige Weg, um festzustellen, ob es sich um einen Mausklick oder einen Tastatur-„Klick“ handelt? Ich hätte wahrscheinlich ein Flag auf Modulebene anhand des zuletzt aufgetretenen Events gesetzt: wenn mousedown neuer ist, dann isKeyboard=false, isMouse=true, und wenn keydown neuer ist, dann umgekehrt.
Dann wären die Funktionen isInvokedByMouse und isInvokedByKeyboard nicht nötig. Gibt es einen besseren Weg? Das von Bildschirmkoordinaten abhängig zu machen, wirkt auf mich sehr fragwürdig und wie ein Hack.
- event.detail [1] ist bei Tastatur-„Klicks“ 0 und bei Pointer-Klicks 1.
  1: https://developer.mozilla.org/en-US/docs/Web/API/UIEvent/det...
Sehr interessant, aber ich verstehe nicht, warum der Browser je nach Monitor unterschiedliche Koordinaten meldet. Ich dachte, der Browser behandelt eine Webseite so, als wäre sie im Vollbild, unabhängig davon, auf welchem Display sie sich befindet.
Gibt es überhaupt einen Grund, warum die Web-API diese Information haben sollte? Das wirkt wie ein Sicherheits-, Informationsleck- und Tracking-Risiko.
Ist das nicht eher eine Frage der Entwicklerkompetenz? Es hätten nicht Bildschirmkoordinaten, sondern Viewport-Koordinaten verwendet werden müssen, also hätte man .clientX und .clientY lesen sollen. Ich verstehe nicht, warum negative Werte im Bildschirmraum ein Bug sein sollen.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSSOM_view/...

BBC-Navigationsleisten-Komponente fiel je nach externem Monitor aus

BBC-Navigationsbug, der nur in einer bestimmten Umgebung reproduzierbar war

Die Reproduktionsbedingung war die Monitorposition

Negative Koordinaten bei screenX und screenY

Unterschiede zwischen Browsern bei Multi-Monitor-Koordinaten

Der tatsächliche fehlerhafte Code und die Korrektur

Verbleibende Designprobleme und anschließendes Refactoring

Verwandte Beiträge

1 Kommentare

Hacker-News-Kommentare

Negative Koordinaten bei `screenX` und `screenY`