folgendes Szenario:
Ein längerer Text wurde in ein Textfeld eines Formulars eingegeben.
Nach dem Absenden wird eine Meldung gezeigt, dass man eingeloggt hätte
sein müssen.
Die Zurückfunktion des Browsers bleibt ohne Wirkung.
Der Text ist offenbar verloren.
Frage:
Werden Texte, die in Textfelder eingetragen werden, in einem
speziellen "Cache" gespeichert?
Danke.
Andreas
--
http://borumat.de
> folgendes Szenario:
>
> Ein l�ngerer Text wurde in ein Textfeld eines Formulars eingegeben.
> Nach dem Absenden wird eine Meldung gezeigt, dass man eingeloggt h�tte
> sein m�ssen.
> Die Zur�ckfunktion des Browsers bleibt ohne Wirkung.
> Der Text ist offenbar verloren.
>
> Frage:
> Werden Texte, die in Textfelder eingetragen werden, in einem
> speziellen "Cache" gespeichert?
Nein.
FF w�re aber nicht FF, w�rde es daf�r keine Extension geben
Lazarus: Form Recovery
https://addons.mozilla.org/de/firefox/addon/6984/
Nette Extension, hatte ich auch benutzt, z.Z geht sie leider nicht mehr
in Minefield...
bye,
Sascha
--
"Not everyone understands House Music; it's a spiritual thing;
a body thing; a soul thing." - Eddie Amador
(c)
np: --
> Lazarus: Form Recovery
> https://addons.mozilla.org/de/firefox/addon/6984/
>
> Nette Extension, hatte ich auch benutzt, z.Z geht sie leider nicht mehr
> in Minefield...
Auf der Hompage gibt's 'ne Beta-Version. Die läuft anscheinend wieder;-)
> folgendes Szenario:
> Ein längerer Text wurde in ein Textfeld eines Formulars eingegeben.
> Nach dem Absenden wird eine Meldung gezeigt, dass man eingeloggt hätte
> sein müssen.
> Die Zurückfunktion des Browsers bleibt ohne Wirkung.
> Der Text ist offenbar verloren.
kenne ich - da schreibt man eine halbe Stunde an einem Forenbeitrag
oder einem Reklamationsschreiben, Klickt auf Senden und dann irgend
eine Fehlermeldung. Sei es "Session abgelaufen" weil man zu lange
gebraucht hat. Oder JS nicht eingeschaltet für diese Funktion. Also
enablen, neuer Seitenaufbau -> alles futsch.
> Frage:
> Werden Texte, die in Textfelder eingetragen werden, in einem
> speziellen "Cache" gespeichert?
Manchmal ja - es liegt wohl an dem "Programm" der Webseite bzw. dem
Script.
Ich drücke fpr dem Absenden fast immer vorsichtshalber ^A^C damit ich
wenigstens den Text in der Zwischenablage habe.
Das Szenario hat wohl jeder schon erlebt. Bei mir oft, weil
zwischenzeitlich die DSL-Verbindung unterbrochen wurde. Meine Frau klagt
auch regelmäßig.
>> Frage:
>> Werden Texte, die in Textfelder eingetragen werden, in einem
>> speziellen "Cache" gespeichert?
>
> Manchmal ja - es liegt wohl an dem "Programm" der Webseite bzw. dem
> Script.
Deshalb steht ja auf manchen Websites extra ein Link "Seite zurück",
damit geht dann meist der Inhalt nicht verloren, nimmt man den Browser
Zurück-Button, passiert das häufiger.
>
> Ich drücke fpr dem Absenden fast immer vorsichtshalber ^A^C damit ich
> wenigstens den Text in der Zwischenablage habe.
Das habe ich mir auch angewöhnt.
Aber die von Sascha erwähnte Erweiterung werde ich gleich mal testen.
Detlef
> FF wäre aber nicht FF, würde es dafür keine Extension geben
> Lazarus: Form Recovery
> https://addons.mozilla.org/de/firefox/addon/6984/
>
> Nette Extension, hatte ich auch benutzt, z.Z geht sie leider nicht mehr
> in Minefield...
Genial!
>> folgendes Szenario:
>
>> Ein längerer Text wurde in ein Textfeld eines Formulars eingegeben.
>> Nach dem Absenden wird eine Meldung gezeigt, dass man eingeloggt hätte
>> sein müssen.
>> Die Zurückfunktion des Browsers bleibt ohne Wirkung.
>> Der Text ist offenbar verloren.
>
> kenne ich - da schreibt man eine halbe Stunde an einem Forenbeitrag
> oder einem Reklamationsschreiben, Klickt auf Senden und dann irgend
> eine Fehlermeldung. Sei es "Session abgelaufen" weil man zu lange
> gebraucht hat. Oder JS nicht eingeschaltet für diese Funktion. Also
> enablen, neuer Seitenaufbau -> alles futsch.
Du sagst es. :(
Ist mir schon etliche Male passiert.
Sehr schade, dass FF da nix von Hause aus anbietet.
Sinnvolle Angebote einer Software bei Bedienfehlern halte ich
innerhalb der großen Gruppe der Merkmale für gute Usability für eines
der hochrangigsten.
> Ich drücke fpr dem Absenden fast immer vorsichtshalber ^A^C damit ich
> wenigstens den Text in der Zwischenablage habe.
Ich auch. Aber Murphy verhindert das manchmal.
Echt ärgerlich, dass es keinen Weg zum Restaurieren gibt.
Andreas
--
http://borumat.de
> > Ich drücke fpr dem Absenden fast immer vorsichtshalber ^A^C damit ich
> > wenigstens den Text in der Zwischenablage habe.
>
> Ich auch. Aber Murphy verhindert das manchmal.
<g> - und immer dann, wenn man gerade besonders viel geschrieben hat.
> Echt ärgerlich, dass es keinen Weg zum Restaurieren gibt.
Nun ja - es gibt ja Lazarus. Einfach genial das Teil!
>> Lazarus: Form Recovery
>> https://addons.mozilla.org/de/firefox/addon/6984/
>>
>> Nette Extension, hatte ich auch benutzt, z.Z geht sie leider nicht mehr
>> in Minefield...
>
> Auf der Hompage gibt's 'ne Beta-Version. Die l�uft anscheinend wieder;-)
Danke!
Andreas
--
http://borumat.de
Hört sich in der Tag sehr gut an.
Schade, dass ich davon nicht schon früher Wind bekam.
Für den vorhin verlorenen Text nützt das leider nix mehr.
Andreas
--
http://borumat.de
> Jens Fittig schrieb:
>
>> kenne ich - da schreibt man eine halbe Stunde an einem Forenbeitrag
>> oder einem Reklamationsschreiben, Klickt auf Senden und dann irgend
>> eine Fehlermeldung.
>
> Das Szenario hat wohl jeder schon erlebt. Bei mir oft, weil
> zwischenzeitlich die DSL-Verbindung unterbrochen wurde.
Das ist Unsinn. HTTP ist ein verbindungsloses Protokoll, d.h. bei jedem
Request wird so oder so eine neue Verbindung zum Server aufgebaut. Wie
und auf welchem Weg, ist dabei vollkommen irrelevant.
Die Ursache liegt vielmehr in den Session-Einstellungen des Servers.
Standardmäßig ist dort ein Timeout von 24 Minuten eingestellt. Wenn Du
in der Zeit keine neue Verbindung aufbaust, wird die Session gelöscht.
Beim nächsten Verbindungsaufbau kennt er Dich dann nicht mehr.
Gruß. Claus
> Die Ursache liegt vielmehr in den Session-Einstellungen des Servers.
> Standardmäßig ist dort ein Timeout von 24 Minuten eingestellt.
Standard von wem oder was? von welchem konkreten CMS, Skript ...
sprichst du?
> Wenn Du
> in der Zeit keine neue Verbindung aufbaust, wird die Session gelöscht.
> Beim nächsten Verbindungsaufbau kennt er Dich dann nicht mehr.
Das kommt darauf an, was der Betreiber / Skriptautor programmiert hat.
Für die Formularverarbeitung als solche sind Sessions völlig
uninteressant und eine bestehende Verbindung braucht es
selbstverständlich nicht. Der Inhalt einer textarea in einem Formular
wird (sinnvollerweise) mit POST übertragen und dann entsprechend den
Anweisungen des hinterlegten Skripts/Programms weiterverarbeitet. Wenn
der Autor da eine IP-Sperre, erforderliche Session, Zufallsgenerator
reinschreibt kann es zu timeouts und Datenverlusten führen. Es ist
Aufgabe des Autors dieses Risiko zu minimieren. Das ist in der WCAG 2.0
sogar mit Prio A versehen.
"Richtlinie 2.2 Ausreichend Zeit: Geben Sie den Benutzern ausreichend
Zeit, Inhalte zu lesen und zu benutzen."
<http://www.w3.org/Translations/WCAG20-de/#media-equiv>
Man könnte also auch mal versuchen zu meckern. ;-)
Gruß
Susanne
So so.
Wenn ich ein Formular ausfülle und es dann absenden will, in dem Moment
aber das Modem disconnected ist, kommt logischerweise eine
Fehlermeldung, z.B. Seite kann nicht gefunden werden o.ä.
Und dummerweise ist dann auch der Text weg.
Da das keine Theorie, sondern selbst erlebte Praxis ist, brauchen wir
darüber nicht weiter zu diskutieren.
Und 'zufälligerweise' weiß ich genau, dass die Verbindung in dem Moment
unterbrochen war.
Detlef
> Schade, dass ich davon nicht schon früher Wind bekam.
> Für den vorhin verlorenen Text nützt das leider nix mehr.
Ich denke, jeder hat schon mal in seinem Leben einen erstellten Text
verloren, z.B. in einer Textverarbeitung. Bei mir war es mal fast ein
ganzer Tag an Arbeit. Jeder weiß inzwischen, dass man diese Regelmäßig
abspeichern sollte.
Bei Formularfeldern hat man sich das wohl noch nicht so richtig angewöhnt.
Wenn ich einen längeren Text in ein Formular zu schreiben habe, erstelle
ich ihn zunächst im Editor und füge ihn dann erst ein.
Hat auch den Vorteil, dass man ihn notfalls auch noch abspeichern kann,
um zu wissen, was man mal geschrieben hat.
Aber bei der angesprochenen Erweiterung erübrigt sich ja (vielleicht)
der ganze Aufwand.
Detlef
> Bei Formularfeldern hat man sich das wohl noch nicht so richtig angewöhnt.
> Wenn ich einen längeren Text in ein Formular zu schreiben habe, erstelle
> ich ihn zunächst im Editor und füge ihn dann erst ein.
> Hat auch den Vorteil, dass man ihn notfalls auch noch abspeichern kann,
> um zu wissen, was man mal geschrieben hat.
Dann wäre "It's All Text!" vielleicht was für dich:
https://addons.mozilla.org/de/firefox/addon/4125/
Ja, danke. Fast so, wie ich es gewöhnt bin, nur etwas schneller/einfacher.
BTW: Gibt es eigentlich eine Obergrenze für Erweiterungen? ;-)
Detlef
> BTW: Gibt es eigentlich eine Obergrenze für Erweiterungen? ;-)
Ja klar. Wenn FF beim Öffnen von <about:blank> mehr als 1GB Speicher
verbraucht...
>> Lazarus: Form Recovery
>> https://addons.mozilla.org/de/firefox/addon/6984/
>>
>> Nette Extension, hatte ich auch benutzt, z.Z geht sie leider nicht mehr
>> in Minefield...
>
> Auf der Hompage gibt's 'ne Beta-Version. Die l�uft anscheinend wieder;-)
Habe die Beta nun ausprobiert.
Alles funktioniert erwartungsgem��, nur ...
... f�hrt die Erweiterung (nach einiger Zeit) zum Einfrieren von FF.
Reproduzierbar.
Eine andere Erweiterung habe ich seit der Installation von Lazarus
nicht installiert.
Vor der Installation von Lazarus hatte ich keinerlei Abst�rze
zubeklagen.
Also abwarten.
Andreas
--
http://borumat.de
> On 11.06.2010 13:43, Claus Reibenstein wrote:
>
>> Die Ursache liegt vielmehr in den Session-Einstellungen des Servers.
>> Standardm��ig ist dort ein Timeout von 24 Minuten eingestellt.
>
> Standard von wem oder was? von welchem konkreten CMS, Skript ...
> sprichst du?
Allgemeiner Session-Timeout in PHP (h�tte ich erw�hnen sollen). Ich
kenne nur wenige Seiten, die diesen Timeout anders einstellen.
>> Wenn Du
>> in der Zeit keine neue Verbindung aufbaust, wird die Session gel�scht.
>> Beim n�chsten Verbindungsaufbau kennt er Dich dann nicht mehr.
>
> Das kommt darauf an, was der Betreiber / Skriptautor programmiert hat.
Nein.
> F�r die Formularverarbeitung als solche sind Sessions v�llig
> uninteressant und eine bestehende Verbindung braucht es
> selbstverst�ndlich nicht. Der Inhalt einer textarea in einem Formular
> wird (sinnvollerweise) mit POST �bertragen und dann entsprechend den
> Anweisungen des hinterlegten Skripts/Programms weiterverarbeitet.
Richtig.
> Wenn
> der Autor da eine IP-Sperre, erforderliche Session, Zufallsgenerator
> reinschreibt kann es zu timeouts und Datenverlusten f�hren.
Genau darum ging es.
> Es ist
> Aufgabe des Autors dieses Risiko zu minimieren.
Genau hier beginnt das Problem.
Auf der einen Seite gibt es - leider - viele Nutzer, die sich nicht
ordnungsgem�� abmelden, wenn sie einen angebotenen Service nicht mehr
benutzen wollen. Das kann aus Versehen passieren (ich nehme mich da
nicht aus) oder auch aus Bequemlichkeit, Faulheit oder einfach nur
Gedankenlosigkeit. Die Folge: Viele Sessions bleiben offen und belegen
unn�tig Speicher. Deshalb werden Sessions nach einer bestimmten Zeit
gel�scht.
> Das ist in der WCAG 2.0
> sogar mit Prio A versehen.
> "Richtlinie 2.2 Ausreichend Zeit: Geben Sie den Benutzern ausreichend
> Zeit, Inhalte zu lesen und zu benutzen."
Damit sind wir auf der anderen Seite.
Zwischen diesen beiden Anforderungen - m�glichst wenig tote Sessions
vorhalten, aber dem Benutzer gen�gend Zeit geben - muss man einen
Kompromiss finden. Der von PHP vorgegebene Timeout von 24 Minuten ist
ein solcher Kompromiss. Die meisten Seiten sind so gestaltet, dass
dieser Timeout ausreicht. Wer Seiten anbietet, die mehr Zeit erfordern,
oder dem Benutzer mehr Zeit geben m�chte, muss entweder diesen Timeout
hochsetzen oder andere Vorkehrungen treffen, um Datenverlust durch
Timeouts zu vermeiden.
Die einfache L�sung (Timeout hochsetzen) ist nicht ideal und auch nicht
100%ig, denn auch ein h�herer Timeout kann ablaufen. Andere Vorkehrungen
sind m�glich (z.B. relogin) und sicher auch sinnvoll, allerdings
entsprechend aufw�ndig.
> Man k�nnte also auch mal versuchen zu meckern. ;-)
Aber nicht, ohne sich vorher an die eigene Nase gefasst zu haben. Wer
Stunden braucht, um seine Adresse in ein Formular einzugeben ...
Gru�. Claus
> Claus Reibenstein schrieb:
>
>> Das ist Unsinn.
>
> So so.
> Wenn ich ein Formular ausfülle und es dann absenden will, in dem Moment
> aber das Modem disconnected ist, kommt logischerweise eine
> Fehlermeldung, z.B. Seite kann nicht gefunden werden o.ä.
Das ist aber ein _anderer_ Fehler als der, der im Ursprungsposting
beschrieben wurde, und liegt noch dazu nicht in der Verantwortung des
Dienstanbieters, sondern des Verwalters der Modemverbindung.
Hat also mit dem hier diskutieren Problem nichts zu tun.
Gruß. Clasu
> BTW: Gibt es eigentlich eine Obergrenze f�r Erweiterungen? ;-)
Bevor Du auch nur in die N�he dieser - physikalisch sicher vorhandenen -
Grenze kommst, d�rftest Du im Zusemmenspiel mancher Erweiterungen schon
l�ngst gen�gend andere "Grenzen" gefunden haben ;-)
Gru�. Claus
> Detlef Meißner meinte:
>
>> BTW: Gibt es eigentlich eine Obergrenze für Erweiterungen? ;-)
>
> Ja klar. Wenn FF beim Öffnen von <about:blank> mehr als 1GB Speicher
> verbraucht...
Bei welchem halbwegs modernen System ist 1GB Speicherverbrauch denn eine
Grenze? Selbst das betagte XP lässt größere Programme zu (bei
95 bin ich mir nicht sicher).
Oder ist dieses Limit fest in FF drin? Das fände ich ziemlich schwach.
Andererseit: Welche besuchenswerte Webseite benötigt so viel Speicher?
Gruß. Claus
Das Problem sehe ich im verschwundenen eigenen Beitrag. Wodurch der
verschwunden ist, halte ich für sekundär, zumal dann, wenn man am/beim
Dienstanbieter nichts ändern kann.
Deshalb ja _grundsätzlich_, also für alle Gelegenheiten, mein Vorschlag,
erst im externen Editor zu arbeiten.
Detlef
Die Frage war durchaus ernst gemeint. Es könnte ja sein, dass die
Erweiterungen in FF zahlenmäßige begrenzt sind, z.B. 300 Stück.
Detlef
> Claus Reibenstein schrieb:
>
>> Detlef Mei�ner schrieb:
>>
>>> BTW: Gibt es eigentlich eine Obergrenze f�r Erweiterungen? ;-)
>>
>> Bevor Du auch nur in die N�he dieser - physikalisch sicher vorhandenen -
>> Grenze kommst, d�rftest Du im Zusemmenspiel mancher Erweiterungen schon
>> l�ngst gen�gend andere "Grenzen" gefunden haben ;-)
>
> Die Frage war durchaus ernst gemeint.
Ach ja? Dann muss ich Dein ;-) wohl falsch verstanden haben ...
http://www.greensmilies.com/smilie-lexikon/
Gru�. Claus
Ja, vermutlich.
Detlef
na ja, *eine* Website wird das kaum schaffen. Aber wenn du zwanzig
Tabs offen hast und ohnehin ca siebzig Extensions ... Damit komme ich
allerdings auch nur auf rd. 250 MByte (FF 3.5.9)
Christoph
--
email:
nurfuerspam -> gmx
de -> net
>>> Wenn Du
>>> in der Zeit keine neue Verbindung aufbaust, wird die Session gel�scht.
>>> Beim n�chsten Verbindungsaufbau kennt er Dich dann nicht mehr.
>>
>> Das kommt darauf an, was der Betreiber / Skriptautor programmiert hat.
>
> Nein.
Doch! ;-) Wer keine Session einsetzt kommt auch nicht mit dem Timeout in
Ber�hrung.
>> F�r die Formularverarbeitung als solche sind Sessions v�llig
>> uninteressant und eine bestehende Verbindung braucht es
>> selbstverst�ndlich nicht. Der Inhalt einer textarea in einem Formular
>> wird (sinnvollerweise) mit POST �bertragen und dann entsprechend den
>> Anweisungen des hinterlegten Skripts/Programms weiterverarbeitet.
>
> Richtig.
>
>> Wenn
>> der Autor da eine IP-Sperre, erforderliche Session, Zufallsgenerator
>> reinschreibt kann es zu timeouts und Datenverlusten f�hren.
>
> Genau darum ging es.
Ja und ich behaupte (ohne belegbare Recherche), dass eine gro�e Mehrheit
dieser Einschr�nkungen komplett �berfl�ssig sind und auf reine
Gedankenlosigkeit der Autoren zur�ckgehen.
>> Es ist
>> Aufgabe des Autors dieses Risiko zu minimieren.
>
> Genau hier beginnt das Problem.
Wieso?
> Auf der einen Seite gibt es - leider - viele Nutzer, die sich nicht
> ordnungsgem�� abmelden,
Wenn ich denn �berhaupt erst mal keine Session brauche, f�llt das
Problem gleich weg.
>> Das ist in der WCAG 2.0
>> sogar mit Prio A versehen.
>> "Richtlinie 2.2 Ausreichend Zeit: Geben Sie den Benutzern ausreichend
>> Zeit, Inhalte zu lesen und zu benutzen."
>
> Damit sind wir auf der anderen Seite.
>
> Zwischen diesen beiden Anforderungen - m�glichst wenig tote Sessions
> vorhalten, aber dem Benutzer gen�gend Zeit geben - muss man einen
> Kompromiss finden.
Mit einem Kompromiss ist es IMHO an dieser Stelle nicht getan
> Andere Vorkehrungen
> sind m�glich (z.B. relogin) und sicher auch sinnvoll, allerdings
> entsprechend aufw�ndig.
Und? Dann sollen die Autoren bitte dar�ber nachdenken und nicht
>> Man k�nnte also auch mal versuchen zu meckern. ;-)
>
> Aber nicht, ohne sich vorher an die eigene Nase gefasst zu haben. Wer
> Stunden braucht, um seine Adresse in ein Formular einzugeben ...
die User beschimpfen, sie seien ja selber schuld. Da kommen wir nicht
zusammen. Ich will als Autorin etwas vom Besucher nicht umgekehrt. :-)
Gru�
Susanne
PS: Ich denke es ist alles gesagt - deswegen habe ich jetzt auf das
X-post verzichtet - wenn nicht sollten wir nach
de.comm.infosystems.www.authoring.misc umziehen.
> On 13.06.2010 15:40, Claus Reibenstein wrote:
>
>> Susanne Jäger schrieb:
>>
>>>> Wenn Du
>>>> in der Zeit keine neue Verbindung aufbaust, wird die Session gelöscht.
>>>> Beim nächsten Verbindungsaufbau kennt er Dich dann nicht mehr.
>>>
>>> Das kommt darauf an, was der Betreiber / Skriptautor programmiert hat.
>>
>> Nein.
>
> Doch! ;-) Wer keine Session einsetzt kommt auch nicht mit dem Timeout in
> Berührung.
Bist Du noch bei der Fehlerbeschreibung des OP? Ich schon.
>>> Wenn
>>> der Autor da eine IP-Sperre, erforderliche Session, Zufallsgenerator
>>> reinschreibt kann es zu timeouts und Datenverlusten führen.
>>
>> Genau darum ging es.
>
> Ja und ich behaupte (ohne belegbare Recherche), dass eine große Mehrheit
> dieser Einschränkungen komplett überflüssig sind und auf reine
> Gedankenlosigkeit der Autoren zurückgehen.
Die "große Mehrheit" beschränkt sich IMHO auf genau zwei der drei von
Dir genannten Punkte: IP-Sperre und Zufallsgenerator. Um die Session
wird man jedoch in vielen Fällen nicht rum kommen.
>>> Es ist
>>> Aufgabe des Autors dieses Risiko zu minimieren.
>>
>> Genau hier beginnt das Problem.
>
> Wieso?
Das habe ich im Folgenden erläutert.
>> Auf der einen Seite gibt es - leider - viele Nutzer, die sich nicht
>> ordnungsgemäß abmelden,
>
> Wenn ich denn überhaupt erst mal keine Session brauche, fällt das
> Problem gleich weg.
Du hast eine Lösung, wie man so etwas ohne Session realisiert? Da bin
ich aber gespannt.
>>> "Richtlinie 2.2 Ausreichend Zeit: Geben Sie den Benutzern ausreichend
>>> Zeit, Inhalte zu lesen und zu benutzen."
>>
>> Damit sind wir auf der anderen Seite.
>>
>> Zwischen diesen beiden Anforderungen - möglichst wenig tote Sessions
>> vorhalten, aber dem Benutzer genügend Zeit geben - muss man einen
>> Kompromiss finden.
>
> Mit einem Kompromiss ist es IMHO an dieser Stelle nicht getan
Hast Du eine bessere Idee? Nur her damit.
>> Andere Vorkehrungen
>> sind möglich (z.B. relogin) und sicher auch sinnvoll, allerdings
>> entsprechend aufwändig.
>
> Und? Dann sollen die Autoren bitte darüber nachdenken und nicht
>
>>> Man könnte also auch mal versuchen zu meckern. ;-)
>>
>> Aber nicht, ohne sich vorher an die eigene Nase gefasst zu haben. Wer
>> Stunden braucht, um seine Adresse in ein Formular einzugeben ...
>
> die User beschimpfen, sie seien ja selber schuld.
Niemand beschimpft hier irgendwelche User.
Fakt ist: Möchte ich die Dienste eines Anbieters in Anspruch nehmen,
muss ich mich in der Regel erst einmal registrieren und künftig jedesmal
anmelden. Anschließend gilt es, ein entsprechendes Formular auszufüllen.
Und hier geht's los:
Fülle ich das Formular ordnungsgemäß aus und schickt es ab, sollte es
keine Probleme geben. Falls doch, versuche ich es eben noch einmal.
Bleibt das Problem bestehen, informiere ich den Betreiber.
Gehe ich jedoch erst einmal Mittagessen und fülle das Formular nach dem
anschließenden Mittagsschlaf aus, darf ich mich nicht wundern, wenn der
Server mich zwischenzeitlich rausgeworfen hat.
> Ich will als Autorin etwas vom Besucher nicht umgekehrt. :-)
Mag sein. Bei meinen Kunden ist es eher umgekehrt.
Mit Mozilla hat das allerdings alles nichts zu tun, deshalb fup2p.
Gruß. Claus
* Detlef Meißner <unge...@mailinator.com>:
> Wenn ich ein Formular ausfülle und es dann absenden will, in dem Moment
> aber das Modem disconnected ist, kommt logischerweise eine
> Fehlermeldung, z.B. Seite kann nicht gefunden werden o.ä.
> Und dummerweise ist dann auch der Text weg.
Wenn man dann nicht auf die Idee kommt, den "Zurück"-Knopf zu
verwenden, sondern stattdessen auf "Neu laden" drückt, sobald
die Verbindung wieder da ist, werden die Formulardaten erneut
geschickt. Dann ist der Text hoffentlich nicht weg.
Christoph
--
In Berlin gibt es die Pfannkuchen sowohl mit Puderzucker als auch mit
Zuckerguss. Beide Arten bekomme ich nur mit Widerwillen herunter. --
"Ein Pfannkuchen mit Puderzucker und Widerwillen, bitte..."
(Dieter Bruegmann, Volker Gringmuth)