"...immer diese Aktion ausführen" funktioniert nicht

Zitat

beim nächsten Klick auf eine Datei desselben Typs dennoch den Dialog wieder angezeigt

Sieht der Server die Dateien auch als identisch an und teilt das über den selben MIME-Type mit?

Beispielseite?

Zitat

Kann den Effekt niemand sonst reproduzieren?

Doch, bei diesem Download schon. Das gilt allerdings nicht allgemein, sondern hat mit einer speziellen Konfiguration des Servers zu tun.
Siehe dazu https://bugzilla.mozilla.org/show_bug.cgi?id=453455 und die dort verlinkten Bugreports.
Viel Spaß beim Lesen der Diskussionen :twisted:

Bei der Diskussion um diesen Bug sind die Mozilla-Entwickler sowas von auf dem Holzweg. Der immer wieder angeführte RFC 2183 bezieht sich auf emails und mail user agents. Damit ist er für den FF irrelevant und betrifft nur TB und den Mail-Clienten von SM. Oder hab ich was verpasst und der FF ist doch ein Mailprogramm? Darf ich jetzt den Kommentar "Der FF ist kein Mailprogramm." nicht mehr anbringen, wenn die Fragen eines Posts offensichtlich auf ein Mailprogramm abzielen?

In einem der Kommentare zu dem Bug wurde auch darauf hingewiesen, das der RFC für den FF irrelevant ist, der Hinweis wurde aber von den Entwicklern ignoriert.

Und selbst wenn der RFC für den FF zutreffen würde - da es sich hier um anzuklickende Links handelt, ist die Hauptforderung des RFC - das der Inhalt nicht automatisch inline angezeigt werden darf, sondern erst eine Aktion der Nutzers erforderlich ist - schon erfüllt. Der Rest wäre kosmetischer Natur und verbietet keinesfalls, nach einem Klick des Nutzers auf das Attachment immer dieselbe Aktion auszuführen. Nur ohne Zutun des Nutzers darf diese Aktion nicht ablaufen. Was auch niemand gefordert hat. Aber wie schon gesagt - der RFC hat keine Relevanz für den FF, und er könnte die Angabe für "Content-Disposition" einfach ignorieren.

Zitat

Der immer wieder angeführte RFC 2183 bezieht sich auf emails und mail user agents.

Ja, allerdings:
http://www.w3.org/Protocols/rfc2….html#sec19.5.1

Zitat

This usage is derived from the definition of Content-Disposition in RFC 1806 [35].

Damit ist dies auch in HTTP/1.1 eingeführt als Ableitung der genannten RFC bzw. deren Aktualisierung (2183). Die dort genannten Prinzipien sind folglich zu übertragen. Somit ist folgende Aussage nicht zutreffend:

Zitat

der RFC hat keine Relevanz für den FF, und er könnte die Angabe für "Content-Disposition" einfach ignorieren

Zitat

ist die Hauptforderung des RFC - das der Inhalt nicht automatisch inline angezeigt werden darf, sondern erst eine Aktion der Nutzers erforderlich ist - schon erfüllt.

Von "inline" ist nicht die Rede:
http://www.ietf.org/rfc/rfc2183.txt

Zitat

2.2 The Attachment Disposition Type

Bodyparts can be designated `attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user.

Und darauf aufbauend folgt eine weiteres Argument von bz:
https://bugzilla.mozilla.org/show_bug.cgi?id=236541#c40

Ich kann daher die Ansicht nicht teilen, dass die Entwickler auf dem "Holzweg" sind. Es ist eine Frage des Standpunktes und der von bz und anderen ist mit Argumenten gefüttert. Es geht nicht um richtig oder falsch, die Entwickler haben sich für einen Weg entschieden, da er ihnen sinnvoll(er) erschien und das ist ihr gutes Recht bei ihrem Software-Produkt.

Zitat von boardraider

Von "inline" ist nicht die Rede:

In dem RFC nicht, jedoch in den Kommentaren zum Bug.

Und wenn du schon RFC 2616 zitierst, dann bitteschön den entscheidenten Part
http://www.w3.org/Protocols/rfc2…15.html#sec15.5

Zitat

Content-Disposition is not part of the HTTP standard,but since it is widely implemented, we are documenting its use and risks for implementors.

Es handelt sich also nur um Empfehlungen, die man beachten kann, nicht aber zwingend beachten muß.

Obwohl ich also nach wie vor keine zwingende Relevanz für den FF sehe: auch wenn man RFC 2183 beachtet, geht daraus nur hervor, das als Attachment gekennzeichnete Teile einer Nachricht (Übertragen auf den FF:Webseite) nicht automatisch im Body (inline :wink: ) der Nachricht angezeigt werden dürfen, sondern eine weitere Aktion des Nutzers erforderlich ist. Und im Falle eines Links ist genau diese Forderung schon erfüllt. Der RFC erfordert keine Rückfrage nach dem Motto "Sie haben einen Link geklickt. Sind sie sicher, das sie die damit verbunden Aktion ausführen wollen?". Und nicht anderes ist es, wenn die Einstellung "immer diese Aktion ausführen" ignoriert wird. Denn das "immer ausführen" bedeutet ja nicht "automatisch ausführen", sondern nur dann ausführen, wenn der Nutzer auf einen entsprechenden Link klickt. Und auch der Hinweis (in den Kommentaren zum Bug) auf
http://www.w3.org/Protocols/rfc2….html#sec19.5.1

Zitat

If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.

ist im Fall des TO (und vielen anderen auch) irrelevant, da der content-Type nicht application/octet- stream ist (hier: text/xml). Und im Fall application/octet- stream werden wohl auch die wenigsten darüber diskutieren, ob "Speichern unter..." die gewünschte Aktion ist.

Ich bleibe dabei: Die Beachtung der Standards in allen Ehren, aber das ist weit über das Ziel hinausgeschossen und somit ein Holzweg. Mit dieser Übererfüllung der RFC's, in Verbindung mit ihrer Uneinsichtigkeit, vergraulen die Entwickler unnötigerweise einen Teil der User, wie sich aus den Kommentaren erkennen läßt.

Zitat

Es handelt sich also nur um Empfehlungen, die man beachten kann, nicht aber zwingend beachten muß.

Touché was die feste Zuordnung zum Standard betrifft. Entscheidet sich allerdings ein Entwicklerteam das zu unterstützen, was Mozilla offensichtlich getan hat, so bleibt es bei der zitierten Ableitung. Soweit sind wir uns sicher einig.

Zitat

sondern eine weitere Aktion des Nutzers erforderlich ist. Und im Falle eines Links ist genau diese Forderung schon erfüllt.

Die beteiligten Entwickler sähen bei der Implementierung eines Automatismus eine Verletzung dieser Regel, insbesondere weil das Klicken eines Links vorab den User nicht darüber informiert, welche Folgen dies hat. Die geforderte "bewusste Aktion" des Users ist hier eben nicht erfüllt.

Zitat

Der RFC erfordert keine Rückfrage

Es ist auch nicht Sinn der RFCs in jedem Fall den UAs vorzuschreiben, wie sie Details implementieren. Diese Freiheit obliegt den Entwicklern, die sie hier auch wahrnehmen.

Zitat

aber das ist weit über das Ziel hinausgeschossen

Die Entwickler sehen es im Rahmen der RFCs und damit konform.

Zitat

in Verbindung mit ihrer Uneinsichtigkeit

Die Frage ist, wer ist hier uneinsichtig? Oder soll man sagen stellenweise respektlos, wenn man sich manche Kommentare dort vor Augen führt? Mir passen auch nicht alle Entscheidungen der Mozilla-Entwickler. So sehe ich hier keinen Zwang dies genau so umzusetzen, vielleicht überraschend trotz der Parteiergreifung. Aber ich nehme es in dem Fall als Entscheidung der Entwickler hin, da ich keine Verletzung von Standards oder einen gravierenden Fehler sehe. Darüber hinaus bestehen nach meiner Einschätzung inzwischen Möglichkeiten das Verhalten über Erweiterungen wie gewünscht zu korrigieren.

Zitat von boardraider

insbesondere weil das Klicken eines Links vorab den User nicht darüber informiert, welche Folgen dies hat. Die geforderte "bewusste Aktion" des Users ist hier eben nicht erfüllt.

Wenn der Nutzer für einen bestimmten MIME-Type eine Aktion festlegt und ein Häkchen macht bei "immer diese Aktion ausführen", dann macht er es bewußt und erwartet, das diese Funktion ausgeführt wird, wenn er einen entsprechenden Link anclickt. Er nimmt es in Kauf, das die Aktion bei jedem Link ausgeführt werden kann, den er anklickt. Außerdem kann das Link-Ziel in der Statusleiste gesehen werden. Und ich sehe nicht ein, warum es ein höheres Sicherheitsrisiko sein sollte, so eine "One Klick Action" bei einem Server zuzulassen der "Content-Disposition attachment" angibt, gegenüber einem Server, der das nicht angibt, insbesondere da es ja nicht Bestandteil von HTTP 1.1 ist und somit content-disposition überhaupt nicht übermittelt werden muß.

Zitat von boardraider

da ich keine Verletzung von Standards oder einen gravierenden Fehler sehe.

Es ist zwar kein festgeschriebener Standard, aber es herrscht allgemeine Übereinstimmung darüber, wenn ein Programm einem User eine bestimmte Aktion anbietet und der User sie wählt, das Programm die Aktion entweder ausführt oder aber mit einer Fehlermeldung reagiert. Alles andere wird allgemein als Fehler betrachtet. FF macht keins von beiden - hat also eindeutig einen Fehler - und erzeugt damit nur unnötige Verärgerung und Verwirrung bei den Nutzern.

Wobei ich selbst das Entfernen der Checkbox bei entsprechenden Downloads für fragwürdig halte. Zumindest ohne gleichzeitig zu informieren warum. Es ist für den durchschnittlichen Nutzer einfach nicht verständlich, warum er eine Aktion, die er doch schon festgelegt hat, immer wieder neu definieren muß und dann noch nicht einmal festlegen kann, das das immer so gemacht wird. Der weiß nichts von Http-headern, content-disposition etc. Und muß er auch gar nicht. Deshalb bin ich weiterhin der Meinung, Mozilla sollte seine Unterstützung der RFC 2138 durch ihren Browser noch einmal überdenken. Oder sie per wenigstens User-Einstellung abschaltbar machen.

Quelle: Junker Jörg

Zitat von Junker Jörg

dann macht er es bewußt und erwartet, das diese Funktion ausgeführt wird, wenn er einen entsprechenden Link anclickt. Er nimmt es in Kauf, das die Aktion bei jedem Link ausgeführt werden kann, den er anklickt. Außerdem kann das Link-Ziel in der Statusleiste gesehen werden.

Das Link-Ziel ist ein URL, mehr nicht. Was sich dahinter verbirgt kann der User vorab und ohne Weiteres nie wissen. Was für einen Server vielleicht zulässig sein soll, muss nicht zwangsweise für einen anderen gelten.

Zitat

es herrscht allgemeine Übereinstimmung darüber, wenn ein Programm einem User eine bestimmte Aktion anbietet und der User sie wählt, das Programm die Aktion entweder ausführt oder aber mit einer Fehlermeldung reagiert.

Dass der Fx die Checkbox nicht ausgraut ist ein Bug, das wird weder von mir noch von den Devs bestritten und ist auch so in der Diskussion mehrfach vermerkt. Darum geht es im Kern der Debatte aber nicht und ist daher auch in einem getrennten Bugreport geführt.

Zitat

Zumindest ohne gleichzeitig zu informieren warum.

Du willst dem gemeinen User erklären, warum sich im Zerrfeld von Standards und realen Gegebenheiten unterschiedliche Meinungen darüber entwickelt haben, wie ein Browser auf den Header im Rahmen der RFCs reagieren soll? Du ziehst doch selbst in Zweifel, dass solche ein User damit etwas anfangen kann. Wozu soll dann eine Information gut sein, die ohnehin nur verwirrt und nicht verstanden wird?

Zitat

Es ist für den durchschnittlichen Nutzer einfach nicht verständlich, warum er eine Aktion, die er doch schon festgelegt hat, immer wieder neu definieren muß

Das kann er durch das Ausgrauen der Checkbox dann nicht mehr. Ergo ist das Verständnis-Problem für den gemeinen User erst gar nicht existent.
Informierte/interessierte User könnten sich nun fragen, warum dies in gewissen Fällen nicht angeboten wird. Diese werden aber größtenteils selbst in der Lage sein sich diese Informationen zu beschaffen.

Quelle: Jackie78

Zitat von Jackie78

ich könnte aus dem Stand dutzende weitere nennen, aller Filetypen und Arten, bei denen das genausowenig funktioniert.

Dann liefere ein Beispiel, dass sich davon signifikant unterscheidet und bei dem es ebenfalls dieses Problem gibt.

Zitat

dann sollte der Fuchs wenigstens so schlau sein und die Checkbox gar nicht erst anbieten

Das ist korrekt und auch so bereits erfasst.

Zitat

Darüber hinaus bestehen nach meiner Einschätzung inzwischen Möglichkeiten das Verhalten über Erweiterungen wie gewünscht zu korrigieren.

Diesbezüglich habe ich kurz mal mit Ubiquity rumgespielt. Das Entfernen des Content-Disposition-Headers sowie das Setzen eines geeigneten Content-Types ermöglicht das direkte Öffnen beliebig bestimmbarer URLs in gewünschten Applikationen, auch wenn der Server selbst es anders anweist.
Damit schränkt sich der Bedarf einer Änderung am Fx-Core weiter ein, da Erweiterungen hier einspringen können.

Zitat von boardraider

Das kann er durch das Ausgrauen der Checkbox dann nicht mehr. Ergo ist das Verständnis-Problem für den gemeinen User erst gar nicht existent.

Du kannst es drehen und wenden wie du willst - das Verständnisproblem bleibt, egal ob die Checkbox nicht macht was sie soll, ausgegraut ist oder gar komplett verschwunden. Stell dir doch einfach nur mal folgendes Szenario vor:

Normaluser klickt auf einen Link, hinter dem sich eine WMV-Datei verbirgt. Firefox fragt "Was willst du damit machen?" Der User sagt "Im Media Player öffnen" , und weil der Server content-distribution nicht übertragen hat - was er auch nicht muß - macht er ein ein Häkchen bei "immer diese Aktion ausführen". Nächste Webseite, wieder ein Link mit WMV, diesmal überträgt der Server "content-distribution: attachment". FF fragt also nochmal "Was willst du damit machen?" User kommt in's Grübeln "Hab ich doch schon festgelegt!?". Also nochmal festgelegt, und oh Schock, "immer diese Aktion ausführen" kann nicht gesetzt werden. Normaluser wird nachdenklich. Neue Seite, wieder ein Link mit WMV, content-distribution wird nicht übertragen, also spielt das WMV brav im Mediaplayer. Normaluser freut sich "Ah! War wohl ein einmaliger Ausrutscher." Doch, zu früh gefreut. Schon bei der nächsten Webseite, auf der er ein WMV ansehen will, wird er wieder mit derselben Frage genervt. Was macht er also? Testet die Seiten im IE. Und siehe da: Nach einmaliger Festlegung hält sich der IE an die User-Vorgabe. Damit ist der FF für Normaluser Geschichte.

Auf diese Weise werden FF-User vergrault. Und alles nur, weil die Mozilla Entwickler im FF einen Standard befolgen, den sie gar nicht befolgen müssen, für einen imaginären Sicherheitsgewinn. Wenn eine nicht erforderliche Funktion in Konflikt mit den User-Erwartungen steht, ist für mich die Lösung offenkundig: Die nicht erforderliche Funktion muß raus.

Man kann es drehen und wenden, wie man will: RFC 2138 wurde für Emails geschrieben und ist deshalb nicht 1:1 auf Webseiten übertragbar. Die User-Erwartungen an das Verhalten eines Email-Clients sind anders als die an einen Browser. Über das "Wie" die Anforderungen der RFC 2138 mit den User-Erwartungen in Übereinstimmung gebracht werden können wird ja anscheinend schon seit Jahren ohne Erfolg diskutiert. Was für eine Verschwendung.

Erinnern wir uns doch mal an die ursprüngliche Idee für den Firefox: ein schlanker (also ohne unnötige Funktionen!) schneller Browser, der sich mit Erweiterungen an die User-Wünsche anpassen läßt. Und nicht ein Browser mit unnötigen nervigen Funktionen, dem man die Flausen durch eine Erweiterung austreiben muß.

Quelle: Junker Jörg

Zitat von Junker Jörg

Damit ist der FF für Normaluser Geschichte.

Wenn ein User seine Entscheidung über die Browser-Nutzung davon abhängig macht, ob dieser Browser die Möglichkeit anbietet, bei einem solchen Header eine Hilfs-Applikation fest und automatisch zu aktivieren, dann ist das natürlich berechtigt. Ob dieses Kriterium aber für die Masse in der Hinsicht Relevanz besitzt bezweifle ich.

Zitat

Und alles nur, weil die Mozilla Entwickler im FF einen Standard befolgen, den sie gar nicht befolgen müssen, für einen imaginären Sicherheitsgewinn.

Sie können ihn befolgen und wie bereits oben erwähnt führt bz auch Fälle an, die über den Sicherheitsaspekt hinaus gehen und bei denen es zu Problemen mit bestimmten Webseiten oder Dateien kommt.

Zitat

Man kann es drehen und wenden, wie man will: RFC 2138 wurde für Emails geschrieben und ist deshalb nicht 1:1 auf Webseiten übertragbar.

Von 1:1 wird an der Stelle nicht gesprochen, sondern von Ableitung. Und diese sollte zumindest die Prinzipien erhalten. Ob im Einzelfall auch einige davon wegfallen können, bedarf einer Diskussion (siehe RFC Empfehlung zur Terminologie), die bereits bei Mozilla geführt und entschieden wurde.

Zitat

Die User-Erwartungen an das Verhalten eines Email-Clients sind anders als die an einen Browser.

Sind sie das in dem Fall? Die Erwartung sich gewisse Automatismen zu merken würdest du bei beiden Programmen haben. Das ist doch ein zentraler Aspekt der Kritik.

Zitat

wird ja anscheinend schon seit Jahren ohne Erfolg diskutiert.

Als Erfolg ist immerhin zu werten, dass der Bug gegenwärtig wieder offen ist, nicht alle Entwickler bei Mozilla sehen es wie bspw. bz. Das Problem ist, dass sich der Sache kein Entwickler annimmt und ich sehe auch keinen Grund warum Entwickler entgegen ihrer eigenen Meinung dort etwas tun sollten. Fx ist immerhin Open Source, wenn sich ein beliebiger Entwickler bereit erklärt einen entsprechenden Patch zu schreiben, wird es sicher schwerer sich dagegen zu wehren.

Zitat

ein schlanker (also ohne unnötige Funktionen!) schneller Browser, der sich mit Erweiterungen an die User-Wünsche anpassen läßt.

Eine Argumentation an der Stelle dreht sich nur im Kreise, da sie ständig von anderen Voraussetzungen ausgeht.
An sich führt es hier auch zu nichts Neuem mehr - wie schon in den Debatten in Bugzilla. Abschließend möchte ich nochmals anmerken, dass ich selbst durchaus die Ansicht teile, dass hier eine bessere Lösung gefunden werden kann. Da allerdings der Fx durch seine Flexibilität und Offenheit die Möglichkeiten bereit stellt, dies auch über eigene Code-Patches oder Erweiterungen zu lösen, sehe ich keinen Zwang eine Lösung unmittelbar im offiziellen Fx einzuführen. Die vielzitierte Freiheit des Users ist im Gegensatz zu anderen Browsern (siehe Opera) auf Grund dessen nicht tangiert.