Zitat von deschen2Hatten wir nicht mal im Rahmen des Community-Umbaus beschlossen, dass wir langfristig gesehen alles nach SUMO umlagern dürfen?
Das war damals schon auf Grund der Bestimmungen nicht vorgesehen, daher wurde das Wiki hier erhalten.
Zitat von deschen2Hatten wir nicht mal im Rahmen des Community-Umbaus beschlossen, dass wir langfristig gesehen alles nach SUMO umlagern dürfen?
Das war damals schon auf Grund der Bestimmungen nicht vorgesehen, daher wurde das Wiki hier erhalten.
ZitatIgnoranten
Ich sehe das nicht so. Dieser "Präzedenzfall" würde einen Wildwuchs dort auslösen, stets mit einem Verweis bspw. auf diese NoScript-Seite. Daher richtete sich mein initialer Vorschlag an das Wiki auf firefox-browser.de (im Übrigen sind beides Wikis!).
Darüber hinaus sind die Bestimmungen dort sehr wohl eindeutig, speziell im Falle von Erweiterungen!
ZitatBeschreibungen, Anleitungen und Problemlösungen zu Software von Drittanbietern sind ebenfalls nicht zulässig. Das betrifft auch Erweiterungen.
Insofern einen Dank an Lendo für den Hinweis. Eine weitere Diskussion darüber erübrigt sich daher.
Auf SUMO macht es keinen Sinn den Artikel weiter zu pflegen. Die Arbeit (insbesondere wegen syntaktischer Unterschiede) sollte sofort in das Wiki zu dieser Seite fließen.
ZitatAber wenn ich das richtig verstehe gibt es Seiten, die den Reload praktisch erzwingen, wo weder Veränderung von browser.sessionhistory.max_total_viewers noch Cacherhöhung hilft.
Richtig. Der Server sagt dem Browser in dem Fall, dass er die Seiten nicht in den Cache aufnehmen soll. Der Fx ist artig und hält sich daran. Daher werden die Seiten neu geladen.
Dir steht es aber frei dich an den Betreiber der Seite zu wenden und dort nachzufragen, ob es denn nötig ist, den Server derart zu konfigurieren.
Alternativ kannst du die vom Server gesendeten Header überschreiben. Entweder mit einem Proxy oder mit Erweiterungen, bspw. https://addons.mozilla.org/en-US/firefox/addon/6371 o. ä.
Zitatwie das technisch überhaupt machbar wäre.
Gar nicht.
Zitat von tom_deaber ich möchte gerne automatisch eine Info, wenn es einen Update gibt und sonst mich nicht drum kümmern oder irgendwo klicken.
Was stört dich dann an der Lösung über Ubiquity?
http://validator.w3.org/check?verbose=…ML%2Findex3.htm
Wäre doch sinnvoll sich an Webstandards zu halten.
ZitatKeine Ahnung welche Forenkultur dir bislang begegnet ist
Wie du da auf Kultur kommst, ist mir ein Rätsel :twisted:
Zitat von G.Incog.Es kommt darauf an was "fertig" ist.
Ich bezog mich dabei auf die Menge an Fehlern und Sicherheitslücken, die in den ersten Wochen behoben wurden. Ich halte das nicht für ungewöhnlich oder sehe darin etwa kritisches. Aber ich sehe dort Muster, die in jedem größeren Software-Projekt zu finden sind. In der Hinsicht ist Google nicht besser wie Mozilla, andersherum aber eben auch nicht.
ZitatWenn jetzt eine API kommt (übrigens nur 1 für Addons, Plugins und Themes - nicht 3 [Addons, Plugins, Greasemonkey]) wird Chrome einen ähnlichen Schub wie FF erleben.
Darauf hoffe ich, damit wäre Chrome der erste Browser seit langem, der mich dazu bewegen könnte dem Fx den Rücken zu kehren.
ZitatUnd fehlerbehaftet ist relativ - gerade dieses Sandboxing ist beim Chrome weit gediehen! --> mit allen Dev Versionen von Chrome 0 bis Chrome 3 hatte ich insgesamt 2 Abstürze eines einzelnen Tabs (dank getrennter Prozesse)
Ein Sandboxing-Modell hat prinzipiell noch nichts mit getrennten Prozessen für Tabs zu tun. Beides kann unabhängig voneinander implementiert werden. Allerdings scheint das Sandboxing bei einigen Schwachstellen eine eine wirksame Barriere einzuziehen. Daher sollte auch Mozilla darüber nachdenken (ich habe in dem Zusammenhang bisher nur von Prozesstrennung gelesen).
ZitatVergleichst du einen frischen FF mit einem frischen Chrome / Safari, hat der Fuchs keine Chance punkto Geschwindigkeit und "Leichtigkeit".
Also bei meinen Versuchen damals war Chrome nicht merkbar schneller als ein jungfräulicher Fx. Die Tests sind inzwischen aber schon eine Weile her. Solche individuellen Stichproben sind aber individuell, Benchmarks dagegen oft realitätsfremd, daher gebe ich auf beides nicht besonders viel.
ZitatDas definitv beste Argument aus Sicht eines Nicht-Entwicklers ist ganz klar ABP
Umso verwunderlicher, dass die Mehrheit der Fx-Nutzer scheinbar keine Erweiterungen einsetzen.
Zitatmeine Kritik war dass sich diese Funktion zu einem Standard unter den Browsern (den bitte immerhin sogar der schlechteste Browser der Welt bietet) entwickelt hat und daher vorhanden sein sollte.
Man muss nicht jeden Käse nachmachen, aber mich stört die Funktion auch nicht, wenn sie vorhanden ist.
@GA
Die Einstellungen des Fx ja, aber das Systemumfeld weicht trotzdem vom anderen ab. Du kennst die üblichen Fehlerquellen und auch wie zuverlässig manche Aussagen von Usern gelegentlich sind :wink:
Ist zufällig lockPref("network.proxy.type", 1); dein erster Eintrag? Dann setze als erste Zeile einen Kommentar, erst danach die Konfigurationen. Hier gelingt das Sperren dieser Einstellung.
ZitatNote that the file must start with //
https://developer.mozilla.org/En/Automatic_M…config_settings
Dann musst du ein anderes Programm verwenden. Offensichtlich produziert es äußert schlechten HTML-Code.
Zitat von angelheart
Ich wersuch schon einige Zeit, die beiden Kampfhähne zu beruhigen.
Das hat, wie in vielen ähnlich gelagerten Fällen, wenig Aussicht auf Erfolg, da gegenseitig die jeweiligen "Argumente" nicht anerkannt und oft sachliche Aussagen persönlich genommen werden. Argumente in Anführungszeichen, da nicht immer beide Seiten wirklich sachliche Einwände einbringen.
ZitatAber das bleibt ja immer im Rahmen einer Diskussion.
Ich persönlich nehme auch kein Blatt vor den Mund.
ZitatBei den beiden will eben immer einer Recht haben
Beim "Recht" haben dreht es sich nicht um das persönliche Triumphgefühl. Cosmo geht es hier um die Hilfeleistung und die Qualität selbiger hier im Forum. Ich bezweifle, dass ihm einer abgeht, wenn er seine Kritik anbringt. Es ist eher frustrierend, dass dies nötig ist. Ihm würde es daher sicher reichen, wenn sachlich auf Argumente eingegangen wird. Aber das können manche eben nicht.
Zitatvlt. sind sie etwas jünger als wir.
Ich würde vermuten, dass sich hier gewisse Alterstrukturen decken, die Frage ist, in welcher Kombination :wink:
Was aber das eigentliche Problem nicht löst, sondern nur umgeht :wink:
Um sich über Updates zu informieren kann man auch Ubiquity in Verbindung mit diesem Command nutzen.
ZitatLeider wird die Datei nach einem Update immer wieder so zurückgesetzt, das der alte Wert (300 kb alle 10 min.) drin steht. Lässt sich das verhindern?
Lass den Wert über ein Skript nach dem Update ändern.
Zitat von _Dani_Alles anzeigenWenn ich dann ca. nach einer halben Stunden nachsehe was der Client macht, sehe ich im Menu Hilfe nur folgendes:
Firefox 3.5.1 wird heruntergeladen...
aber das bleibt dann die ganze Zeit so....Stundenlang. Auch wenn ich den Firefox zwischendurch neu starte.
[...]
Aber eigentlich sollte das ja automatisch im Hintergrund laufen
[...]
Hat jemand eine Idee woran das liegen könnte?
Es läuft doch automatisch im Hintergrund, allerdings mit langsamer Geschwindigkeit:
http://mxr.mozilla.org/mozilla1.9.1/s…teService.js.in
const DOWNLOAD_CHUNK_SIZE = 300000; // bytes
const DOWNLOAD_BACKGROUND_INTERVAL = 600; // seconds
const DOWNLOAD_FOREGROUND_INTERVAL = 0;
Also 300.000 Bytes in 10 Minuten, daher kann so ein Update-Prozess u. U. im Hintergrund auch etwas länger dauern.
Manuell angestoßen wird natürlich nicht gebremst.
Dann solltest du prüfen, welche Schreibrechte für das Programmverzeichnis vergeben sind.
In deiner Signatur steht ja nicht, ob ein Update mit eingeschränkten Rechten möglich ist oder welches Dateisystem du verwendest :wink: