Firefox "Bestätigung"

[hoster]

Kann man das bei Firefox irgendwie abstellen?

 

[PaRaDoX]

Das dürfte m.E. eher ein Sicherheitsfeature sein, welches es nicht nur bei Firefox gibt. Damit verhinderst du u.a. doppelte Bestellungen/Postings.

Wenn ich mich nicht irre, tritt das auch nur auf, sofern du den "zurück"-Button nutzt.

Wenn es deaktivierbar sein sollte, stellt sich immernoch die Frage nach dem Sinn.

Korrigiert mich wenn ich Schwachsinn verfasst habe.

 

[hoster]

Ja, ist immer wenn ich zurück-Button benutze
Es nervt einfach auf dauer
Ich würde es gerne für ein paar Websites deaktivieren wo ich ganz sicher weiß, dass da keine Bestellungen oder Doppelpost´s etc. entstehen können

 

[memcpy]

Die vorherige Seite könnte dynamisch anhand einer "POST request" Nachricht erzeugt worden sein. Diese Nachricht muss somit nochmals gesendet werden um eine bestimmte Ressource abrufen zu können.
Diese Meldung erscheint somit bei "Zurück" und "Neuladen" einer entsprechenden Seite.

 

[accC]

Gewöhn wir einfach ab den Zurück / Vorwärts - Button zu benutzen.
Das ist ein Feature und ich wüsste nicht, dass sich das deaktivieren lässt.

 

[BurnerR]

Normalerweise sollten entsprechende Seiten ihre eigenen Navigationsbuttons anbieten.

 

[Novgorod]

Gewöhn wir einfach ab den Zurück / Vorwärts - Button zu benutzen.

ja, super tipp - und wenn windows update mal zickt, führ es einfach nie aus ..

eigentlich sollte man mit vor/zurück im cache browsen können, um schnell irgendwohin zurückzukehren, ohne die seite neu laden zu müssen.. leider wurde dies bei POST-seiten offenbar abgeschafft (das aber schon seit etlichen jahren) und man kann diese nicht mehr aus dem cache erreichen (und sowas wie "in neuem tab/fenster öffnen" gibts bei den üblichen POST-buttons ja nicht, sondern nur bei GET-links).. der "gedanke" war wohl dahinter, doppeltes abschicken von formularen zu verhindern, aber genau das passiert ja, wenn die zurück-funktion die seite (inkl. POST) komplett neu lädt anstatt sie aus dem cache zu holen.. wenn sich der entsprechende cache auch nicht in den tiefen von about:config einschalten lässt, dann gehts nicht mit firefox...

 

[BurnerR]

Genau das habe ich auch nie verstanden, wäre fein wenn jmd nen guten Grund anführen kann.
Meinem verständnis nach sollte es auch so sein, dass beim Betätigen des "zurück" Buttons gar keine Kommunikation mit dem Server stattfinden soll sondern komplett der ursprüngliche Status der Seite aus dem lokalen Cache genommen wird.

 

[theSplit]

Nur noch mal zur Ergänzung, man kann mit Rechtsklick auf den Zurück Button den Verlauf des Tabs öffnen und damit diese Meldungen soweit umgehen das man auf Seiten kommt, wo man keine Daten an den Server versandt hat.

Da käme man auch zu einem Thema, den Server mit POST durch Back-Button drücken zu bombadieren oder einen Artikel 10 mal in die Liste aufzunehmen oder ein Bild dreimal zu uploaden.. mach doch irgendwo Sinn.

Strg+T öffnet den letzten geschlossen Tab mit Verlauf bzw. Tabs aufeinander rückwärts folgend, sofern man nicht Inkognito surft.

 

[BurnerR]

Was ich als Nutzer - vielleicht bin ich da auch einfach speziell - erwarte, wenn ich auf "zurück" klicke, dass ich dann genau die selbe Seite vor mir habe wie vorher. Dazu ist Kommunikation mit dem Server nicht erforderlich. Stattdessen werden dynamische Inhalte neugeladen, was ich immer wieder unpraktisch finde.
Ich würde dann vielmehr eine Mitteilung des Browsers erwarten, dass Teile des Inhaltes nicht mehr gültig sind, da dynamisch generiert etc. oder das bestimmte Knöppken nicht mehr richtig funktionieren oder deaktiviert sind oder oder. Das fände ich alles sinnvoller als mir eine neu generierte Seite vom Server zu präsentieren, das ist doch kein "Zurück", sondern ein "Alte Seite neu laden", wenn ich die aber neu geladen haben will möchte ich auf "Neu laden" drücken, nachdem ich auf "zurück" geklickt habe. Wenn ich nur zurück will ohne neu laden möchte ich nur auf "zurück" klicken, soweit zum Wunsch ;-).

 

[Shodan]

Genau das habe ich auch nie verstanden, wäre fein wenn jmd nen guten Grund anführen kann.

Das liegt an dem Design des http Protokolls. Ich versuche das mal leicht verständlich (d.h. vereinfacht) darzustellen:
Mit http greifst du auf die Ressource an einem bestimmten Ort, identifiziert bei einer Unique Resource Location (URL) zu. Für die Art des Zugriffs gibt es verschiedene Aktionen, unter anderem GET und POST. Erstere liefert dir die an diesem Ort liegende Resource, letztere gibt ihr Daten zum verarbeiten.
Wenn du nun beispielsweise Daten sendest, die dann in eine Datenbank eingetragen werden und eine Bestätigung erhältst, und dann sendest du die selben Daten noch einmal, dann ist die Bedeutung der Anfrage nicht: Zeige mir (noch einmal) die Bestätigung, sondern: Schreibe diese Daten (noch einmal) in die Datenbank.

Was ich als Nutzer - vielleicht bin ich da auch einfach speziell - erwarte, wenn ich auf "zurück" klicke, dass ich dann genau die selbe Seite vor mir habe wie vorher.

Die History ist nicht eine History der Resourcen hinter der URL zum Zeitpunkt an dem sie geschrieben wurde, sie eine History der URLs, die aufgerufen wurden und wie (been there, done that).
Kleines Beispiel: du bist auf der Twitter Seite eines Freundes. Der hat drei Tweets, die du siehst. Du surfst woanders hin und klickst dann auf zurück.
Wenn der in der Zwischenzeit einen vierten Tweet geschrieben hat, willst du die alte Resource (drei Tweets) oder du willst die neue Resource (vier Tweets) an dem Ort "Twitter Seite eines Freundes"?

Die Frage ob die History sich wie ein Cache verhalten soll, oder die Resource immer wie zum Zeitpunkt der Anfrage darstellen soll, ist sehr alt. Der Weg ist in Richtung Cache gegangen und ich denke nicht, dass sich das noch mal ändert.

Aber wir entfernen uns immer weiter von der Sache. Es gibt durchaus Möglichkeiten Formulare die POST nutzen zurückknopffreundlich umzusetzen. Das ist Aufgabe des Webmasters. Macht er das nicht richtig, dann sehen die Nutzer die Meldung im Startpost. Das gilt als "user unfriendly". Es gibt nichts, was du clientseitig dagegen tun kannst, außer dem Webmaster eine Mail zu schreiben

 

[accC]

ja, super tipp - und wenn windows update mal zickt, führ es einfach nie aus ..

Das war nicht meine Aussage. Wenn Windows Update zickt, dann installier dir Linux oder reparier Windows halt.
Es ist ja keine Fehl-Funktion des Firefox, sondern eine bewusst eingeführte Schutzfunktion.

Genau das habe ich auch nie verstanden, wäre fein wenn jmd nen guten Grund anführen kann.
Meinem verständnis nach sollte es auch so sein, dass beim Betätigen des "zurück" Buttons gar keine Kommunikation mit dem Server stattfinden soll sondern komplett der ursprüngliche Status der Seite aus dem lokalen Cache genommen wird.

Na pass auf: [Bestellung Absenden] - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor
Wie oft hast du jetzt den Artikel in den Warenkorb gelegt und/oder bestellt. Beim zurück hast du ja nichts gemacht, beim vor allerdings schon, oder?

Das Problem ist, dass du nicht einfach nur mit cache arbeiten kannst, willst und darfst. Gerade bei Bestellformularen ist ein Cache gar nicht mal sinnvoll.
Wenn ich meinen Warenkorb bei Amazon aufrufe, wäre es doch dämlich, würde mein Browser hierfür eine gecachte Version laden. Ich bestelle ja nicht etwa immer das gleiche sondern viel mehr bei jedem Checkout andere Dinge. Daher will man hier überhaupt keinen Cache an dieser Stelle. Auch dem Händler ist das gar nicht so lieb, er muss eventuell auf preisliche Änderungen reagieren können und die muss er dir mal mindestens vor Abschluss der Bestellung mitteilen.

 

[Novgorod]

Wenn du nun beispielsweise Daten sendest, die dann in eine Datenbank eingetragen werden und eine Bestätigung erhältst, und dann sendest du die selben Daten noch einmal, dann ist die Bedeutung der Anfrage nicht: Zeige mir (noch einmal) die Bestätigung, sondern: Schreibe diese Daten (noch einmal) in die Datenbank.

äh ja, aber die funktion des zurück-buttons ist es doch nicht nochmal auf "senden" zu drücken, wenn die vorherige seite ein formular war .. aber ich seh schon - wenn man auf eine seite zurückkehren will, die per POST und nicht per GET aufgerufen wurde (also die seite NACH dem abschicken des formulars und nicht das formular selbst), will er die POST-daten nochmal schicken und das finde ich eben unsinn in verbindung mit dem zurück-button.. in deiner analogie: ja, ich will einfach nochmal die bestätigung sehen und nicht erneut was an den server schicken, denn ich gehe davon, aus dass vor/zurück einem "offline-browsing" entspricht, so wie es ja mal war.. die meldung macht nur dann sinn, wenn man auf der bestätigungsseite ist und nochmal POSTen will, indem man z.b. F5 drückt (was die seite ja per POST refresht) - da man es hier ja explizit vom server neu anfordert, macht die meldung sinn, um doppeltes abschicken zu verhindern bzw. davor zu warnen..

aber es kann doch nicht so schwer sein, die zurück-funktion entsprechend korrekt umzusetzen, oder? GET-seiten kommen ja auch direkt aus dem cache, obwohl da beim zurück-klicken ja eigentlich eine URL aufgerufen wird, oder? gibts da vielleicht ein addon?

Wenn der in der Zwischenzeit einen vierten Tweet geschrieben hat, willst du die alte Resource (drei Tweets) oder du willst die neue Resource (vier Tweets) an dem Ort "Twitter Seite eines Freundes"?

das ist doch klar: wenn ich auf den ort zugreife (link, adresszeile, F5, wie auch immer), dann will ich die neue ressource.. nehme ich den zurück-button, will ich einen "snapshot" von genau dem was im cache ist - das war doch eigentlich der sinn der sache, sonst könnte man auch den cache gleich abschalten und nur eine URL-history führen..

Na pass auf: [Bestellung Absenden] - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor
Wie oft hast du jetzt den Artikel in den Warenkorb gelegt und/oder bestellt. Beim zurück hast du ja nichts gemacht, beim vor allerdings schon, oder?

nein, nach meinem verständnis "macht" man nur dann was (kommunikation mit dem server), wenn man auf POST-buttons oder links klickt (oder die adresse eingibt), aber nicht beim vor/zurück, das sollte nämlich komplett offline ablaufen.. offenbar denkt man bei den browserherstellern nicht so..

Wenn ich meinen Warenkorb bei Amazon aufrufe, wäre es doch dämlich, würde mein Browser hierfür eine gecachte Version laden.

das ist aber bevormundung und in diesem fall nervt es mehr als es "schützt".. der user sollte die kontrolle darüber haben, was er aus dem cache lädt und was nicht, das ist die einzige sinnvolle herangehensweise - und gleichzeitig sollte dem user klar sein, dass man per zurück-button nur die alte version (dafür aber ohne ladezeit und server-kommunikation) bekommt und wenn man seinen warenkorb aktualisieren will, klickt man eben auf den warekorb-link oder drückt F5.. nochmal: man kann statt vor/zurück einfach jeden link (auch POST-aktionen, wenn man das irgendwie hinbekommt) in einem neuen fenster/tab öffnen - das kann kein webmaster verhindern oder abfragen - und dann eben zu dem tab mit der gewünschten version wechseln anstelle des zurück-buttons.. nun will man statt dem tab-wirrwarr einfach im cache browsen und man lässt uns nicht ...

 

[accC]

Ich weiß nicht genau, wie das Cache-Management abläuft, soweit ich weiß, wird doch quasi gefragt, ob sich die Seite seit dem letzten Besuch geändert hat..
entweder ja => Seite neu vom Server laden
oder nein => Seite aus dem Cache holen

Bei dynamischen Seiten, insbesondere wo Sessions eine Rolle spielen wird das vermutlich immer der Fall sein..

Ich bin mir aber nicht sicher.

 

[BurnerR]

Na pass auf: [Bestellung Absenden] - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor - zurück [zu Artikelauswahl] - vor
Wie oft hast du jetzt den Artikel in den Warenkorb gelegt und/oder bestellt. Beim zurück hast du ja nichts gemacht, beim vor allerdings schon, oder?

Drücke auf "Vor" bedeutete dann natürlich auch Laden aus dem Cache.

Ich weiß nicht genau, wie das Cache-Management abläuft, soweit ich weiß, wird doch quasi gefragt, ob sich die Seite seit dem letzten Besuch geändert hat..

Kann mir vorstellen, dass das genau der Punkt ist und es historisch bedingt ist, dass Browser sich so verhalten, weil der Mechanismus noch aus einer Zeit stammt wo es vielmehr statische Inhalte gab (wo das dann ja auch Sinn macht) was dann über die Jahre durch mehr und mehr dynamisch generierte Inhalte abgelöst wurde.

 

[Shodan]

das ist doch klar: wenn ich auf den ort zugreife (link, adresszeile, F5, wie auch immer), dann will ich die neue ressource.. nehme ich den zurück-button, will ich einen "snapshot" von genau dem was im cache ist - das war doch eigentlich der sinn der sache, sonst könnte man auch den cache gleich abschalten und nur eine URL-history führen.

Ein Cache ist ein wenig komplizierter und dient in erster Linie dazu unsinnige Kommunikation zu vermeiden: Verbessert die Ladezeit, reduziert die Datenmenge. Er dient explizit nicht dazu veraltete Resourcen vorzuhalten. Auch ist der Browser nicht der einzige Cache, Server zwischen dir und der Location können ebenfalls Caches betreiben. Gerade wegen letzterem ist die Spezifikation des Protokolls eben so aufgebaut, dass Anfragen per POST idR nicht gecached werden dürfen. Ich will gar nicht so genau drauf eingehen: Wenn dich die Details interessieren, lies die RFC 7234 "Hypertext Transfer Protocol (HTTP/1.1): Caching".

In der gibt es im übrigen einen Abschnitt 6 der dir insofern zustimmt, als dass es keine Vorschrift ist, dass die History und Zurück-Funktionalitäten eines Browsers das "freshness Model" umsetzen müssen. Imho ein Fehler, aber dazu später mehr.

Wie ich in meinem letzten Post schon anmerkte wurde darüber auch lange diskutiert. Ich benutzte ja nur ungern ein Autoritätsargument, aber hier muss es dann doch mal sein. Aber nur, weil über die Verhaltensweisen einer Anwendungssoftware reden: Die Entwickler haben sich dabei etwas gedacht und die wissen was sie tun:
Legende hat es, dass es die Banken waren, die am Ende der Diskussion massivst Druck auf Mozilla ausgewirkt haben. Die Zurück-Funktionalität soll wohl Daten auch dann vorgehalten haben, wenn sie mit "no-cache" "no-store" und über SSL ankamen. Das war zwar sehr "user friendly" aber nur, bis der User aufstand und weg ging ohne seine History zu leeren. Dann konnte sich jemand anders an den Rechner setzen und per Zurück einfach über den An/-Abmeldevorgang hinweg die gespeicherten Seiten hinter dem Login anschauen. Auch heißt es Nutzung des Firefox 3.0 sei für die französische Onlinewahl deswegen ausgeschlossen gewesen, da man in dem "Speicher" (Cache war es ja nicht, hielt sich ja nicht an die Regeln) nachsehen, wie der vorherige Nutzer des Rechners gestimmt hat.

Wenn eine Seite, zum Beispiel hinter einem Login, ein no-store sendet, dann hat der Browser das zu respektieren. Wenn Zurück sich nun wie der Offline-Modus verhält, dann bekommst du eben eine "Seite ist lokal nicht verfügbar, klicken sie reload um die Liveversion zu sehen". Und dann gibt es auch wieder Tränen deswegen Dann machst du eine Mischlösung: Veraltete Resourcen werden im alten Stand angezeigt, aber no-store Seiten werden geladen. Leider macht lieber jeder Browser was anderes.

Lass uns lieber mal auf heise.de gehen!
Die Hauptseite sendet: "Cache-Control: public, max-age=32"
Warte weniger wie 32 Sekunden. Drück in der Navigationsleiste Enter. Die Seite kommt aus deinem Cache.
Warte mehr wie 32 Sekunden. Drück in der Navigationsleiste Enter. Die Seite wird neu vom Server geladen.

Geh auf einen Artikel.
Warte weniger wie 32 Sekunden. Drück auf Zurück. Die Seite kommt aus deinem Cache.
Warte mehr wie 32 Sekunden. Drück auf Zurück. Die Seite kommt aus deinem Cache.

Überraschung: Der Button macht genau das was du willst.

Ein anderes schönes Beispiel ist ein Forum in dem ich manchmal rumhänge: ngb.to

Ich schreibe also einen Beitrag, klicke auf Vorschau. Dann ändere ich den Beitrag, klicke wieder auf Vorschau.
Mit dem Vor- und Zurückbutton kann ich nun zwischen dem alten und neuen Stand hin- und herwechseln. Ohne Serverinteraktion, nur aus dem lokalen Cache. Obwohl sie die selbe Location haben. Der Grund dafür ist, dass der Vorschau Button einen Post Request auslöst und die Antwort direkt für diesen kommt, ganz ohne "Post Redirect Get" oder sowas. Klicke ich auf Vorschau und dann auf Reload, so bekomme ich die Meldung aus dem Starter. Warum? Weil ich den Browser anfordere einen Post noch mal an den Server zu senden.

Nachteil hier ist halt: Melde ich mich ab, ohne den Beitrag abzusenden und gehe weg, ein anderer könnte sich an meinen Rechner setzen, auf Zurück klicken und einen Beitrag lesen, den ich nie gepostet habe. Die Webmaster des Forums sehen das als unbedenklich und schieben die Verantwortung für das Leeren des "BFCaches" (Back-Forward Cache) auf den User.

Der Punkt den ich verdeutlichen will ist: Cache-control ist Sache des Webmasters. Firefox unterstützt, was du willst. Mit der Einschränkung, dass es nicht deine Entscheidung ist, ob eine Seite aus dem Cache geladen werden KANN. Die gehört dem Webmaster, denn der kann sagen: Diese Seite enthält Informationen, die geheim sind, aber meine User sind dumm, rufen sie aus Internetcafes auf, gehen weg ohne den Cache zu leeren. Und das ist ein berechtigtes Interesse.

Und nun ist die Frage: Warum ist die Meldung aus dem Starter bei Vor und Zurückbuttons trotzdem so häufig anzutreffen? Der Grund dafür ist einfach: Der Webmaster macht seine Aufgabe nicht ordentlich. Wenn seine Seite auf einen POST nun mal "Cache-Control: no-store, no-cache, must-revalidate" sendet, dann soll er bitte auch "Post-Redirect-Get" benutzen. Macht er das nicht, ist die Usability im Eimer. Aber das ist doch nicht Schuld des Browsers.
Der versucht nur, es möglichst vielen recht zu machen. Dazu zählt unter anderem halt auch, dass der BFCache veraltete Seiten anzeigt, aber ein explizites "must revalidate", "etag" und "vary" respektiert. Seiten wie Twitter könnten (Konjunktiv: ich weiß nicht, ob sie es wirklich tun) argumentieren, dass ihre User bei einem "Zurück" auch neue Tweets erwarten und die wenigen, die unbedingt "stale content" sehen wollen, sollen eben den Offline Modus anschalten.
Die Argumentation ist einfach: Die meisten User verstehen nichts von "lokalen Kopien", sie haben gerade erst kapiert, dass die Seiten nicht auf ihrem Rechner, sondern im Internet sind. Wir wollen die jetzt nicht mit "mit diesem Knopf sind sie im Netz und mit diesem auf deinem Rechner" verwirren.
Deine Ansicht war die Ansicht der RFC 2616. Aber es ist nicht mehr 1999. Mit Breitbandinternet überall und Millionen von Nutzern, die schon mit dem Anschalten des Rechners fast überfordert sind geht der Weg immer weiter davon weg.

Ich gehe sogar soweit und sage: Es ist eine Katastrophe, dass du mit drei Browsern vier unterschiedliche Verhaltensweisen der Buttons hast, denn was hat uns Jahre der Diskussion über diese Thematik gebracht?
Webseiten mit eigenen Vor- und Zurückbuttons, Webseiten die beim Nutzen der Browserbuttons komische Meldungen anzeigen. Manager, die ihre Webmaster für unfähig halten, weil der eigene Zurück-Button was anderes macht wie der des Browsers. Sinnfreie "no-store, no-cache, must-revalidate" (alle drei auf einmal, damit auch IE8 es versteht), die eigentlich nur Traffic verschwenden.

 

[Novgorod]

Ich weiß nicht genau, wie das Cache-Management abläuft, soweit ich weiß, wird doch quasi gefragt, ob sich die Seite seit dem letzten Besuch geändert hat..
entweder ja => Seite neu vom Server laden
oder nein => Seite aus dem Cache holen

ja, das ist die "normale" aufgabe des caches, wenn man eine seite aufruft (link, adressleiste, F5), um eben unnötigen traffic zu verhindern.. nutzt man vor/zurück, sollte garnichts vom server abgefragt werden (nicht einmal ob sich was verändert hat) und alles aus dem cache kommen.. aber es ist ja nicht mehr 1999 und es ist deshalb kein problem, server mit milliarden unnötiger requests zu bombardieren und user warten zu lassen ..

Der Punkt den ich verdeutlichen will ist: Cache-control ist Sache des Webmasters. Firefox unterstützt, was du willst. Mit der Einschränkung, dass es nicht deine Entscheidung ist, ob eine Seite aus dem Cache geladen werden KANN. Die gehört dem Webmaster, denn der kann sagen: Diese Seite enthält Informationen, die geheim sind, aber meine User sind dumm, rufen sie aus Internetcafes auf, gehen weg ohne den Cache zu leeren. Und das ist ein berechtigtes Interesse.

und das ist eben nicht sache des webmasters, ebensowenig wie referrer, werbung, darstellung und skripte! es ist nichts anderes als ein vorschlag oder eine bitte des webmasters, denn am ende entscheidet immer der user, was er mit den vom server gesendeten daten macht, und wenn er dafür nen eigenen browser entwickeln muss..

ja, ich weiß, wir haben es heerscharen von apple-idioten, die nicht wissen wie man einen computer einschaltet (zumindest werben sie ja damit), zu verdanken, dass das internet vor die hunde geht, aber warum muss ich das immer ausbaden!? und ja, ich kann die gründe wunderbar nachvollziehen und alles, daher habe ich auch überhaupt kein problem damit, wenn das bei mainstream-software (wie firefox) als default so umgesetzt wird (offenbar ist es also schlimmer wenn jemand mit dem zurück-button einen abgebrochenen post oder den kontostand sieht, als die tatsache, dass derjenige bereits zugriff auf alle lokalen daten hat, da der PC ungesichert im öffentlichen raum steht, aber gut)..

und abgesehen von der (idiotischen) "philosophie" entspricht es ja auch nicht der realität, dass der webmaster mit irgendwelchen HTTP-flags kontrolle über die lokale nutzung der daten bekommt.. man kann wie gesagt jeden link in einem neuen tab öffnen und schon hat man die "offline-history", die der webmaster verhindern wollte.. genauso kann man die gerade dargestellte webseite jederzeit abspeichern und später wieder abrufen, also ist diese art von DRM allein schon prinzipbedingt wirkungslos.. wenn der webmaster "geheime informationen" (lol ) geheim halten will, dann sollte er sie eben nicht per HTTP (oder überhaupt) verschicken, denn die einzige "sicherheit" ist das vertrauen darauf, dass der browser sich an die vorschläge des servers hält und die daten nicht anderweitig abgegriffen bzw. gespeichert werden - also blanker unsinn, was das "sicherheits-argument" angeht..

von mir aus können sie die defaults so lassen wie sie wollen und noch 5 jahre lang darüber streiten was neu geladen werden soll und was nicht.. ich will doch einfach nur meine kontrolle wiederhaben, ohne mit ner million tabs rumzuhantieren oder den browser wechseln zu müssen.. ein haken in den einstellungen oder ein addon würde doch schon reichen und den apple-nutzern müsste man es auch nicht verraten ...

 

[accC]

ja, das ist die "normale" aufgabe des caches, wenn man eine seite aufruft (link, adressleiste, F5), um eben unnötigen traffic zu verhindern.. nutzt man vor/zurück, sollte garnichts vom server abgefragt werden (nicht einmal ob sich was verändert hat) und alles aus dem cache kommen..

Okay, dann vielleicht so: Der Vor- bzw. Zurück-Button wurde aber eben nicht als Snapshot-Tool entwickelt, sondern um die vorherige Seite aufzurufen.

Wenn dich die Argumentation von Shodan nicht überzeugt, dann bleibt eigentlich nur noch Kugelfisch..

 

[Novgorod]

Der Vor- bzw. Zurück-Button wurde aber eben nicht als Snapshot-Tool entwickelt, sondern um die vorherige Seite aufzurufen.

na das stimmt so aber nicht, denn statische seiten werden mit dem zurück-button doch (immernoch?) aus dem cache geladen und nicht vom server, d.h. der button ist nicht dasselbe wie ein link bzw. die adresseingabe in die adressleiste.. bei letzterem findet immer eine server-kommunikation statt (das html-dokument wird geladen), es werden höchstens ressourcen übersprungen, die sich nicht geändert haben (bilder, stylesheets, was noch?)..

ansonsten bin ich voll und ganz überzeugt - ich lehne es nur ab ..

 

[Verbogener]

Strg+T öffnet den letzten geschlossen Tab mit Verlauf bzw. Tabs aufeinander rückwärts folgend, sofern man nicht Inkognito surft.

Also wenn ich einen leeren Tab benötige, dann verwende ich meistens STRG+T. Das ist glaube ich schon immer so im FF gewesen. Und ich verwende ihn schon seit der 0.7 oder so ähnlich. Auf jeden Fall unter der 1.x.

Cu
Verbogener