Closed adressler closed 11 years ago
Moin,
Danke für den Hinweis. Klar du kannst alle Methoden des Objektes ausführen. Das wäre sicher eine gute Alternative zu dem window.scrollTo. Eigentlich war das eh nur ein schneller bugfix welcher mal abgelöst werden sollte.
Ehrlich gesagt kann ich den Fehler nicht nachvollziehen. In all meinen Tests mit diversen Browsern lief das immer so wie es sollte. Kann es sein das hier noch eine andere Extension mit reinspielt?
Eine andere Erweiterung sollte da nicht reinspielen, da kaum etwas installiert ist in der Installation. Meiner Erfahrung nach sind nicht alle Browser wirklich mit allem fertig, wenn domready aufgerufen wird. Safari springt z.B. nach einem Reload automatisch selbst an die Stelle, wo das Dokument vorher stand und kommt möglicherweise dem manuellen Scrollversuch in die Quere. So einen Fall hatte ich schonmal auf einem iOS-Device, bei dem man mit dem manuellen scrollTo die Browserleiste verstecken kann. Dort musste man auch ein paar Millisekunden vor dem Aufruf warten... Opera z.B. löst kein Scrollevent aus, wenn der Browser bereits an 0,1 steht und Du dort hinscrollen willst (ebenfalls nach Reload). Ich kann den kleinen Patch gerne noch im IE testen. Mir scheint der direkte Aufruf der Funktion stabiler zu sein als der Umweg über das Event.
Ja ondomready ist dann fertig wenn der dom eingelesen wurde was der Hauptunterschied zu onload ist, da hier solange gewartet wird bis auch alle Bilder und co geladen wurden.
Die Infos zu den Unterschiedlichen Browsern sind sehr interessant, gut zu Wissen.
Ich mache jetzt mal ein Hotfix fertig in dem die init Methode am Ende die setItem Methode triggern wird und dann können wir gerne mal testen.
Vielen dank das du deine Hilfe anbietest.
Klar gerne. Dafür sind die öffentlichen Repositories doch da ;) Ich teste gerade viel mit Contao 3.1 RC/dev rum und versuche mich in die Weiterentwicklung von Core und Modulen einzubringen. Ich hatte Dir eben einen Tweet geschickt (weiß leider nicht, ob der an den richtigen Account ging g), ob Du eventuell auch m17PageFolders bei github reinstellen magst.
So ich habe im Branch hotfix-2.0.4 ein update eingespielt. Hab den Fix unter Safari, Opera und Chrome auf mac getestet und lief :)
Freue mich über dein Feedback.
Ich hab dir via Twitter geantwortet :) Finde ich richtig gut was du machst, nur so können Erweiterungen besser werden. Für Version 3.0. der Extension ist eh ein kompletter Rewrite des StickyBackendFooters geplant aber erstmal sehen wir zu das die Kinderkrankheiten raus kommen.
Danke dir!
Habe 2.0.4 mit Safari, FF, Chrome, Opera (unter OS X) und IE 10 (Win8) getestet und keine Probleme mehr festgestellt.
Der kleine Darstellungsfehler im Opera ist dann wohl ein neues Ticket – falls irgendwer Interesse an Opera hat :)
Sehr gut. Der Hab mir den Opera Bug schonmal angesehen. Der Opera kommt nicht mit der getStyle('width') methode klar von mootools. Mal sehen ob ich hier nen workarround schreibe :) Auf jeden Fall mache ich mal ein Ticket auf.
Ich stelle die Änderung dann mal ins ER. Besten Dank nochmals.
Hallo, das Verhalten ist in jedem Browser anders, was die initiale Positionierung beim erstmaligen Aufrufen oder Reload einer Seite angeht. Nach einigen Tests bin ich darauf gekommen, dass es etwas mit dem Event zu tun hat, welches Du mit dem
this.scrollTo(0,1)
auslösen möchtest. Dies scheint nicht immer wie gewünscht zu feuern. Ich habe etwas rumgespielt und festgestellt, dass Du anstelle desscrollTo
auch einfachM17StickyFooter.setItem()
aufrufen kannst. Damit klappt es bei mir zuverlässig in Safari, Firefox, Opera und Chrome. Den IE habe ich noch nicht getestet.Getestet mit dem aktuellen github-master, Contao 3.1.RC1 und den jeweils aktuellen Browserversionen.
PS: Im Opera hat der sticky Footer die falsche Breite, ist nur so breit wie die Buttons im Footer und geht nicht über die volle Breite der Spalte