Der Block id=„cookie-consent“ ploppt bei mir bei jedem Seitenaufruf für ein paar Millisekunden oben Link auf. Ist der im Standard so, dass er draussen ist und per Javascript auf left: 0 gestellt wird?
Danke und Gruss
Ohh - das hat aber Potenzial num nerven 
Im Chrome kann ich das eigentlich nicht beobachten - ggf. ganz selten mal. Auch nicht im Firefox.
Aber im Edge (alte Version) ist das ganz fürchterlich. Jeder Seitenaufruf zeigt die Config-Seite an, und scrollt erst mit erheblicher Verzögerung raus.
@Shopware das ist eine sehr schlechte Umsetzung - und nervig für Kunden. 
Das ganze „Tool“ wirkt, wie mit der „Heißen Nadel gestrickt“
Moin zusammen!
Das Problem an diesem Verhalten ist, dass sich die Nachstellbarkeit als schwierig gestaltet.
Das Ganze scheint irgendwie mit Caching und Browser- bzw. Client-Performance zusammen zu hängen.
Ich konnte das Verhalten nur effektiv nachstellen, wenn ich meinen PC zum Rauchen gebracht habe - und in diesem Szenario konnte ich das Verhalten auch beheben.
Dadurch ist das schon zu großen Teilen eingedämmt worden.
Warum einige Benutzer das in manchen Konstellationen weiterhin nachstellen können, ist mir leider auch nicht ganz klar.
Und zu der anderen Frage: Nein, das startet nicht mit „left: 0“, es wird der Code hier genutzt.
Das Problem ist vermutlich(!), dass das Element von Haus aus in Plain HTML erstmal sichtbar wäre - wenn die .css Datei also etwas Zeit zum Laden braucht, wird der o.g. Style natürlich erst nachträglich angewandt.
Ein potenzieller Fix könnte es sein, wenn man das Element per Inline Style direkt aus dem sichtbaren DOM entfernt.
Wenn ihr das zuverlässig nachstellen könnt, wäre ich euch sehr dankbar, wenn ihr das einfach mal testen könntet.
Ich bekomme es leider absolut nicht mehr hin dieses Verhalten nachzustellen und kann daher momentan leider nur raten, was eine Lösung angeht.
Lieben Gruß
Patrick Stahl
Also diesen Mist habe ich schon von Anfang an. Hatte ich aber auch schon mal gepostet. Zunächste dachte ich, das es nur in Google Chrome DEV Version so rumspackt, jedoch sehe ich mittlerweile auch in anderen Browsern immer wieder kurz aufblitzen… 
Ich teste gerade mal rum.
Wie gesagt: Am “Schlimmsten” ist es mit dem Edge.
Die Bar scheint erst zu verschwinden, wenn das HTML ganz geladen ist.
Hat jetzt eine Seite “wenig” Inhalt, ist die Bar kaum bis nicht zu sehen.
Seiten mit nur Einkaufswelten sind da weniger anfällig, da ja die Elemente (default) per JS nachgeladen werden. Somit ist bei einer großen Seite mit vielen Elementen das HTML dennoch “klein”. Gehe ich jetzt auf eine Seite mit Listing, bleibt die Bar stehen, bis die Seite geladen wurde (oder Kontaktformular mit mehr Text bei mir). Manchal poppt die Bar dann sogar ein zweites Mal auf.
Mit inline-style komme ich auf die Schnelle auch nicht weiter.
Durch “left:0” wird es zunächst festgenagelt. Erst später wird mit “.off-canvas.is–left” mit translateX auf -100% verschoben - und bei open auf 0%.
Egal was ich dann im Inline-Style setze: es überschreibt dauerhaft das CSS. Da müsste man zunächst inline auf translateX(-100%) setzen, und das Inline dann per JS entfernen.
Wir macht Ihr dass den mit dem “Mobile-Menü” und der “Off-Canvas-Cart”? Die “poppen” ja auch nicht auf.
Ah ok, als schnell Abhilfe folgender Rat, folgendes in die eigene CSS hinzufügen:
.off-canvas { left:0;}
damit hört das Ploppen auf, aber die Sidebar verbreitert sich etwas nach recht beim Kategorieaufruf, was nur etwas weniger schlimm ist wie das ploppen.
Aber das eigentliche “Problem” ist eigentlich, dass id=“cookie-consent” innerhalb von “.content-main–inner” steckt. Gibts dazu einen Grund warum das nicht nach dem Footer kommt?
Hm, wo finde ich „die eigene CSS“? Was meinst Du damit? Habe nur das Standard-Theme.
Wo finde ich die Datei? Und wo gebe ich dann Deinen Code ein?
Hi, das sollte in einem eigenem Theme organisiert werden.
@Murmeltier [@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl “Patrick Stahl”) und alle anderen, ich muss leider von dieser Lösung abraten, sonst funktionieren die Filter nicht mehr!
Macht auch keinen Sinn, etwas auf „left:0“ zu setzen, weil es das per CSS ja schon ist, und 0 die erste „sichtbare Stelle links“ ist.
Erst durch „translateX(-100%)“ wird das Element um die „volle Breite“ weiter nach Links verschoben, und verschwindet damit.
CSS Left:0 ist eigentlich sofort verfügbar, translateX (je nach Browser?) wird aber erst ausgeführt, wenn das DOM komplett geladen ist - und darum poppt es auf.
An „.off-canvas“ rumpfuschen ist eher ungünstig, ist ja eine allgemeine Class - auch für Cart und Mobile-Menü.
Sollen die eine Lösung finden, die dafür bezahlt werden
1 „Gefällt mir“
[…] Sollen die eine Lösung finden, die dafür bezahlt werden
Werden Sie aber wohl nicht, da es ja nur ein paar Menschen betrifft… und es nicht „nachstellbar“ ist… 
Macht doch erstmal ein Ticket auf, damit sich das jemand ansehen kann.
Gerne dann hier im Thread verlinken.
Das müsste schnellstens behoben werden, weil es Kunden verschreckt! Ich würde auch nicht auf einer Webseite weiter klicken, wenn sich da was im Hintergrund zusätzlich lädt!
Habe jetzt schon diverse Nachfragen von Kunden erhalten, was da im Hintergrund geladen wird!
Außerdem finde ich die Cookie-Variante nicht gut gelöst. Es müsste ganz einfach 1 Button: „Zustimmen“ und 1 Button „Konfigurieren“ erscheinen.
Guten Morgen!
Ich beschäftige mich gerade mit diesem Thema, kann das Problem aber leider ebenfalls nicht reproduzieren.
Getestet wurden bisher Firefox, Chromium, IE8, IE11, Edge 80 und Edge 15.
Es wäre toll, wenn ihr noch weitere Informationen zu der Umgebung nennen könntet in der das Verhalten auftritt,
bspw. Browserversion und installierte Extensions.
Abgesehen davon konnte ich aber eine Situation simulieren in der das Verhalten auftritt und habe vielleicht einen Fix.
Wäre jemand hier bereit, das einmal auszuprobieren? Die nötigen Änderungen (Patch) findet ihr hier, die
Zeilennummern und Dateien sind dort vermerkt, falls git im Einsatz ist kann man das Ganze auch mittels
git apply [patchdatei]
anwenden.
Im Endeffekt wird hier der Cookie-Consent-Manager generell versteckt, bis er zum ersten Mal geöffnet wird.
So sollte beim Laden der Seite keinerlei Animation gestartet oder überhaupt gezeigt werden.
Viele Grüße aus Schöppingen
Philip Gatzka
Das Problem: Ich habe 2 Shops, auf dem gleichen Server. Bei einem ist das Problem zu 99% nicht zu reproduzieren, auf dem anderen hingegen zu 99% z.B. im Kontaktformular An dem würde ich nur ungerne Live rumspielen, aber ich werde es laufe des Tages mal machen. Ein wenig misstrauisch bin ich aber noch: mach ich dort einen „Reload“, verschwindet die Bar nach kurzer Zeit, aber poppt noch ein zweites Mal auf
Den ersten „diff“ verstehe ich nicht ganz - da ist doch kein Unterschied ?!?
Werde mich melden…
Hallo @sonic
danke für deine Unterstützung, ich wollte hier allerdings nicht dazu aufrufen, live-Shops anzupassen 
Wenn keine passende Testumgebung vorhanden ist, dann solltest du das
Risiko natürlich nicht eingehen.
Zum Diff - hier sind die Zeilen 9 und 21 interessant, in Zeile 9 ist die is–hidden Klasse
im div dazugekommen, in Zeile 21 wird die Klasse vom consent-manager wieder
entfernt.
Viele Grüße aus Schöppingen
Philip Gatzka
@philipgatzka
Die beiden Dateien hand-ge-patcht - zumindest bei mir flackert es nun nicht mehr im Edge 44.18362.449.0 (wo finde ich die Version? *lol*), Chrome & Firefox (Nachtrag: IE 11 ist auch ok) 
Wollte nur nicht am Shop frickeln, wenn Chef Produkte anlegt - hat er aber gerade nicht 
Zu oben: War zu blöde, den ersten Diff pro Datei als Dateinamen der Patches zu deuten *schäm*
1 „Gefällt mir“
Alles klar, danke für Deine Hilfe! Dann werde ich noch einmal die exakte Edge-Version testen um das hier nachzustellen.
@philipgatzka
Was mir noch vor dem patch aufgefallen war:
Wenn es richtig hakelig war - vorzugsweise unser Kontaktformular fast immer - poppte die Bar oft ein zweites mal auf, was laut CSS ja garnicht hätte passieren können.
Könnte es sein, dass hier das translateX im Edge sowohl durch CSS als auch modernizr ausgeführt würde? Kommt diese Version vom modernizr ggf. nicht sauber mit translateX und/oder dem Edge zurecht?
Ist es möglich, dass das „Fehlverhalten“ ohne Patch gar durch den modernizr verstärkt worden ist?
Edit: der „modernizr“ ist ja auch schon seit 3 Jahren nicht mehr aktualisiert worden… in der Zeit hat sich bei den Browswern aber schon ein wenig getan 
Könnte man ja mal auf die ToDo-Liste setzen…
Edit2: Ticket https://issues.shopware.com/issues/SW-25205