und das selbe im Interpreter (Vorschaumodus)

und das selbe im Normalmodus ...

Was ist das für ein Pfad K:\\\......?  MAchst du immer einen Export auf ein Laufwerk und testest es dann in den Browsern?

Da kann zu solchen Fehlern kommen, weil es keine Serverumgebung hat wo die Skripte ausgeführt werden können. Der Vorschaubrowser kann eine vorgegaukelte Serverumgebung erzeugen.

Der Fehler tritt nur in der fertigen Homepage auf, egal, welcher Browser, im Vorschaumodus in X5 pro wird aber alles korrekt dargestellt. Ich habe es aus dem Webserver heraus, als auch durch Aufruf der Index.html aus dem Ablageverzeichnis (Hier K:\) probiert ... in der fertigen - uploadbaren - Seite funktioniert es nicht, egal welchen Menütyp ich nehme.

Ich habe es mit mehrere Vorlagedateien versucht und auch eine Seite komplett neu erstellt.

In der Evolution 13 tritt der Fehler nicht auf, aber in der aktuellen X5 Professional.

Ist der Hamburgerbutton so gewünscht?  Wenn nicht, dann sind die MEnübutton zu breit oder das Menü-Objekt zu zu kurz eingestellt.

Vor Design her könnte vielleicht im Projekt einmal STRG+Vorschau helfen.

Und nochmals ein Export auf ein Laufwerk und mit diesen Daten testen kann zu Fehlern führen.

Entweder nur am Vorschaubrowser testen oder direkt auf dem Server die Daten spielen und testen.

Ich habe die Breite des Menübuttons auf EIN Feld reduziert, das Problem bleibt, ALLE Tests wurden vom Webserver durchgeführt, die lokalen Tests habe ich ausgelassen.

Das Problem tritt beim Hamburgerbutton und im Standardmenü auf, egal wie breit ich den Menübutton mache. Siehe auch Bild-gescroll.jpg und Bild-gescroll2.jpg 

Ich habe jetzt auch unterschiedliche Layouts benutzt, auch dort gibt es das Problem.

In der Evolution 13 tritt der Fehler nicht auf, aber in der aktuellen X5 Professional, ich habe testweise die URSPRÜNGLICHE - nicht upgedatete X5 pro installiert, auch dort ist der Fehler nicht vorhanden, erst nach dem Update.

Zudem ist mir aufgefallen, dass bei Hamburgermenü am Handy alle Menüpunkte (außer Start) doppelt angezeigt werden, am PC nicht.

Das selbe mit einer anderen Homepage ...

und gescrollt

Ok, Danke, ich probiere es ... das erklärt für mich aber noch nicht, dass, wenn ich die pro neu installiere, alles funktioniert und nach dem Update auf die 16er nicht mehr.

Apropos: Ich habe folgende Stellungnahme von Mozilla (Firefox) erhalten, die von Google (Chrome) ist ähnlich:

Comment # 3 on Bug 1471894 from Brad Werth [:bradwerth]at 2018-06-28 14:10:28 PDT This is a tough one. I've convinced myself that the value we wish would be zero is coming from some jQuery: "p=a.parent().offset().left" The jQuery offset() function does appear to call getBoundingClientRect(), according to https://searchcode.com/codesearch/view/79669847/ So this is following a code path that matches the bug found in our regression range. It may be that the library could be made correct if the code "g=function(){return-o.scrollLeft()+l+p}" was changed to omit the addition of the "p" value, but it's impossible to discern the semantics of that with the mini-fied JS. I'll see if I can find an un-mini-fied version of the library and propose a semantic fix to the library authors.

Übrigens Danke für den Hinweis "dass seit der V13 das Hauptmenü nicht mehr verbunden ist mit dem Header", dessen war ich mir SO nicht bewußt.

Ich habe es probiert ... Ergebnis bleibt, obwohl es deutlich größer ist

Ergänzung: Der Menübalken rutscht unterschiedlich weit nach recht, je nachdem wie groß das Fenster ist, in dem ich es öffne. Der Abstand bleibt dann GLEICH, wenn ich das Fenster vergrößere oder FullScreen gehe

Ergänzung seitens Modzilla:

New theory: the value is getting exposed through a jQuery call to retrieve

the marginLeft property on the computed style. I can't extract the JS stack from my debugger to figure out the exact path, but when I zero out the > value, we get the desired behavior. However, in all the tests I can think to try, FF and Chrome returns the same values for marginLeft on elements with > margin: auto. So that might indicate there is a UA-specific behavior in either jQuery or the Website X5 library.

jQuery does some feature detection about "reliableMarginLeft", and FF is currently marked as false: https://github.com/jquery/jquery/blob/ > 9a5b3b6ed0803d816984718de23d6af451260c89/test/unit/support.js#L177 Chrome is marked as reliableMarginLeft: true.

I attempted a UA spoof to a Chrome string, but it didn't change the test site behavior in FF. I'm going to continue to investigate how jQuery does  browser detection and see if I can confirm that this reliableMarginLeft property is the culprit. Ugh, nice catch! Yeah, looks definitely related... What they do is falling back to a getBoundingClientRect() calculation: https://github.com/jquery/jquery/blob/e743cbd28553267f955f71ea7248377915613fd9/src/css.js#L394 And our getBoundingClientRect().left is exactly what they shift the bar. This is really annoying. :((

Die Erklärungen von Modzilla nützen nichts und können in WSX5 nicht verwendet werden. WEnn du einen Fehler im FF hast, dann muss etwas bei dir bei der Installation von FF nicht funtkioniert haben.

Aber wir reden hier ja über das MENÜ oder?

Du bist ja in der Stickybar und hast das Menü eingestellt. Das ist aber nur das Scrollmenü und nicht das Hauptmenü!  Das Hauptmenü kann man unter "Inhalt des Template" einstellen, vielleicht ist das der Fehler.

Tja, wenn ich in der Stickybar alle Menüs in allen Auflösungen lösche und im Hauptmenü komplett neu anlege, passiert genau das, was ich hier schildere, nur dass zuerst (auch dort) sofort ein Hamburgermenü angezeigt wird, das ich erst durch Größenänderung anpassen muss, wie anschließend in der Stickybar ... auf die Idee bin ich auch schon gekommen, ich habe auch das Templet neu geladen.

Wenn ich die pro (mit der Erstinstallation ohne Updates) neu installiere, funktioniert alles und nach dem Update auf die 16er nicht mehr.

Du meinst in der V14 oder V15 funtkioniert es und in der V16 verschiebt es alles?  Oder meinst du die erste Version von V16.0.0 auf die derzeitige V16.1.0?

Habe das selbe Problem. Nach Update auf V16.1.1 Im Firefox wird die Stickybar deutlich nach rechts verschoben dargestellt. Mit anderen Browsern kein Problem.

In der V14.x, V15.x und V16.0 funtkioniert alles, der Fehler tritt ab der Version V16.1.x auf.

Hi Franz, Andreas.

Are you able to create a new project, very simple and light, and send it here so that we might check it? Because I wasn't able to reproduce the issue you mentioned.

You can use Wetransfer service (https://wetransfer.com/), or another one of your choice, upload your .iwzip project online, then select "link" and generate the download link that you can post here on Help Center.

Keep me posted

Stefano

GOOGLE TRANSLATE ---

Hallo Franz, Andreas.

Können Sie ein neues Projekt erstellen, sehr einfach und leicht, und senden Sie es hier, damit wir es überprüfen können? Weil ich das von Ihnen erwähnte Problem nicht reproduzieren konnte.

Sie können entweder Wetransfer (https://wetransfer.com/) oder einen anderen Dienst wählen, den Sie bevorzugen, und die .iwzip Datei Ihres Projektes Online hochladen, dann "Link" wählen und einen Downloadlink generieren, den Sie dann hier auf dem Help Center posten können.

Halte mich auf dem Laufenden

Stefano