Skip to content

v1.15.9 - Position-Marker erscheint endlich (CSS-Bug behoben)

Choose a tag to compare

View all tags
@Xunil99 Xunil99 released this 20 May 17:58
v1.15.9
a9a0e6b

Der eigentliche Marker-Bug

Nach mehreren Iterations-Runden hat ein gezieltes Konsolen-Diagnose-Script die Ursache aufgedeckt:

canvas:         0,53  686x800
projOnCanvas:   343,486
markerViewport: 320,1359   ← 820 px tiefer als erwartet!
window:         686x924

Erwartet wäre markerViewport.y = 539 (= canvas.y 53 + projOnCanvas.y 486). Tatsächlich war er bei 1359, weit unterhalb des Bildschirms.

Ursache

In meiner CSS-Klasse .ebike-3d-marker und im Inline-Style des Marker-Elements stand position: relative. Das hat MapLibre's eigenes position: absolute überschrieben.

MapLibre platziert Marker normalerweise so:

  • position: absolute auf dem Marker-Element
  • transform: translate(x, y) relativ zum Container-Ursprung

Mit meinem position: relative Override:

  • Der Marker fällt zurück in den normalen DOM-Flow
  • Das transform: translate(x, y) wird relativ zu seiner Flow-Position appliziert
  • Da das Marker-Element weit unten im DOM-Tree des Karten-Containers liegt, landet die natürliche Flow-Position ca. 820 px tiefer als erwartet
  • Marker rutscht außerhalb des sichtbaren Bereichs

Warum hatte ich position: relative überhaupt drin?

Als Positioning-Context für den pulsierenden ::before-Ring. Aber MapLibre's eigenes position: absolute auf dem Marker erfüllt diese Rolle bereits — die Pulse-Animation funktioniert auch ohne meinen Override.

Fix

position: relative aus CSS und Inline-Style entfernt. Marker landet jetzt exakt dort, wo MapLibre ihn projiziert. Pulsierender Ring funktioniert unverändert.

Nach dem Update

HACS-Update auf 1.15.9 (manuell anstoßen falls noch nicht angeboten), HA-Neustart, Browser-Hard-Reload. Tour öffnen.

Erwartet:

  • Grüner pulsierender Marker sichtbar an Bike-Position (mit chase_lookahead: 30 Default im unteren Drittel, mit chase_lookahead: 0 mittig)
  • Oranger Start-Marker am Tour-Anfang
  • Roter Ziel-Marker am Tour-Ende

Sorry für die lange Iteration

Die letzten ~5 Versionen haben versucht, den Bug an den falschen Stellen zu lösen (doppelte Inits, Race-Conditions, Browser-Caches, Look-Ahead-Geometrie). Der eigentliche Übeltäter war ein einziger CSS-Override, der mit den vorherigen Diagnostiken nicht direkt sichtbar wurde. Dein Konsolen-Output mit canvas-rect + projection + getBoundingClientRect war der entscheidende Datenpunkt.

Assets 7
Loading