Huhu,
ab dem heutigen Nightly wird der Bugfix zu Bug 367596 (Create about:support page with troubleshooting information) enthalten sein. Das sieht dann so
[Blockierte Grafik: http://img34.imageshack.us/img34/3964/troubleshootinginformat.th.png]
aus und ist über "about:support" oder auch "Help"/"Troubleshooting Information..." aufrufbar.
Wird dann ab Fx 3.6 (der Checkin in den 1.9.2-Branch folgt bald) die Hilfe hier im Forum erleichtern, denke ich :-).
Ermm, das ist doch ein normales Verhalten?!
Bei *mir* ist es schon seit eh und je so, dass lediglich der Login via HTTPs abgewickelt wird, der Rest läuft unverschlüsselt (von den Bezahlvorgängen einmal abgesehen).
Zitat von PalliEntscheidend ist nicht ob die Seite verschlüsselt ist, sondern ob deine Daten verschlüsselt übertragen werden.
Richtig. Man lese z.B.: http://www.heise.de/ct/Sicher-uebertragen--/hotline/142795 (Hotline Tipp aus der aktuellen c't).
So,
ich nutzte auch eine FRITZ!Box Fon WLAN 7170 mit aktiviertem "Fernzugriff" und "Dyndns" Funktion.
(1) Ein erster Aufruf der Dyndns-URL ergibt bei mir:
[Blockierte Grafik: http://img34.imageshack.us/img34/5670/fbfz01.th.png]
(2) Auf die Schaltfläche "Ausnahmen hinzufügen" geklickt folgt:
[Blockierte Grafik: http://img142.imageshack.us/img142/33/fbfz02.th.png]
(3) Dabei wird das Zertifikat automatisch geladen und die Option "Diese Ausnahme dauerhaft speichern" ist aktivierbar. Es folgt:
[Blockierte Grafik: http://img142.imageshack.us/img142/2323/fbfz03.th.png]
(Die HTTP Access Abfrage des Fernzugriffs der FRITZ!Box)
(4) Firefox bietet dann auch das Abspeichern dieses Passwortes an und die Routeroberfäche wird geladen:
[Blockierte Grafik: http://img142.imageshack.us/img142/669/fbfz04.th.png]
(5) In der "Larry UI" kann man dann prüfen, dass es sich um eine permanente Ausnahme handelt:
[Blockierte Grafik: http://img142.imageshack.us/img142/6722/fbfz05.th.png]
(6) Zudem auch im PSM/NSS:
[Blockierte Grafik: http://img142.imageshack.us/img142/867/fbfz06.th.png]
Wo hängt's bei dir?
Zitat von BoersenfegerDas ist mein Provider, habe aber, wie gesagt das Problem derzeit nicht. Welcher wäre das denn?
http://kundenservice.freenet.de/hilfe/komplett…ex.html?state=0
DNS-Redirect deaktivierenDurch das Hinterlegen einer speziellen DNS-Adresse können Sie die Anzeige der freenet Serviceseite deaktivieren.
Diese Adresse lautet: 194.97.173.124 oder 194.97.173.125
Zitat von DAC324
Aber wenn das unter
http://ftp.mozilla.org/pub/mozilla.or…de.langpack.xpi
tatsächlich immer tagesaktuell ist, kann ich meine Arbeit hier beenden.
Errrm, täglich generierte langpack.xpi gibt es aber schon seit einigen Monaten, ist dir das etwa erst jetzt aufgefallen?
Btw, via http://hg.mozilla.org/l10n-central/de/pushloghtml sieht man die aktuellen Checkins in den "de-DE l10n Zweig".
Ich dachte immer,dass du den Kram hier nur deshalb machst, weil du "andere Übersetzungen" nutzt?!
Zumindest freenet gibt einen alternativen DNS-Server an wo dieser Kram nicht stattfindet.
Ermm, ich meinte für Fx 3.7a1pre 
Wir brauchen doch auch unseren Trunk Thread 
Per https://wiki.mozilla.org/Firefox3.5/Sta…-15#Engineering und "Bugzilla Talk" wird es wohl nächste/übernächste Woche den 1.9.2 branch geben.
Der 1.9.2 branch wird für Fennec 1.0 benötigt.
Geht dann also mit Gecko 1.9.3a1pre/Fx 3.7a1pre auf Mozilla Central (auch als "Trunk" bekannt) weiter ;-).
Neuer Thread oder Umbennenung?
Zitat von ffFanwenn das Datengrapschen so weiter geht...geolocation...google-proxies...prefetch-next)
Solche Funktionen sollten prinzipiell erstmal ausgeschaltet sein
Geolocation: ist "Opt-in", lässt sich via about:config auch pauschal deaktivieren, eine UI-Integration ist geplant.
Google-Proxies: wtf?
Prefetch-next: wird von dem Webseitencode gesteuert, lässt sich via about:config deaktivieren.
Und wo findet jetzt nochmal "Datengrabschen" statt?
Bzgl. der Abstürze:
Nach einer Aktualisierung beim Hersteller der Erweiterung angefragt?
Nenne einmal ein paar CrashIDs.
Man lese https://bugzilla.mozilla.org/show_bug.cgi?id=452530
insbesondere https://bugzilla.mozilla.org/show_bug.cgi?id=452530#c0.
please change the url for the eBay search plug in per a request from eBay due to some system upgrades on their side the new url should be: http://rover.ebay.com/rover/1/707-37276-17702-4/4?satitle={searchTerms}
Die URL lautet also seit Fx3.0.4, 3.5.0 und auch im l10n de-DE trunk so.
Das von den meisten hier geschilderte Problem ist in der Tat kein Einzelschicksal, sondern betrifft viele Nutzer des Fx 3.5.
Eine Komponente des Fx ("NSS" (Network Security Services)) durchsucht die temporären Dateien sowohl vom IE als auch von Windows was zur Verlangsamung des Startvorgangs führt.
Ein entsprechender Bugreport in der Bugdatenbank Bugzilla wurde bereits erstellt: https://bugzilla.mozilla.org/show_bug.cgi?id=501605 (bitte *nicht* kommentieren, CCen gerne)
Die l10n-Nightlies wurden in den letzten beiden Tagen in Mozilla-Central (a.k.a. "Trunk") getestet, jedoch gab es da wohl einige Probleme in Form von "Sprachen-Mischmasch": https://bugzilla.mozilla.org/show_bug.cgi?id=480081#c55
Hoffentlich geht's nächste Woche dann endgültig los :).
- Rechts-Klick auf die Firefox 3.5 Desktop-Verknüpfung
- "Eigenschaften" auswählen
- Schaltfläche "Ziel suchen" anklicken
Es öffnet sich dann ein Explorer-Fenster mit dem Inhalt des Firefox Installationsordners (inkl. Unterordner etc. pp).
Dort *muss* ein Unterordner "Updates" ersichtlich sein.
Das ist ein bekannter Bug und kein Problem einer Anpassung/einer Erweiterung.
Als 1. Workaround kann man einen Rechtsklick auf die Menüleiste/Toolbar durchführen und "anpassen" auswählen. Nach dem Schließen des "Anpassen"-Fensters sind die Pfeile weg.
=> https://bugzilla.mozilla.org/show_bug.cgi?id=447571 (nicht (!) kommentieren)
=> https://bugzilla.mozilla.org/show_bug.cgi?id=447571#c0 (1. Workaround)
=> https://bugzilla.mozilla.org/show_bug.cgi?id=447571#c66 (2. Workaround: Extension von Alice White)
Zitat von pcinfarktEin MU wird es bei künftigen Sicherheits- und Stabiltätsupdates und vor EOL Fx 3.0.* geben [1]. Vllt. auch schon eher. Wer weiß!
[1] https://www.camp-firefox.de/forum/viewtopi…=529838#p529838
https://bugzilla.mozilla.org/show_bug.cgi?id=459878
=> getestet wurden die MUs von 3.0.x -> 3.1/.5 immer mal wieder bereits im Entwicklungszyklus von Fx3.5, um Probleme bereits im Vorfeld zu minimieren.
Ich schätze mal, dass es das erste MU erst mit 3.5.1 (also Fx3.0.13 -> 3.5.1) geben wird (Fx3.0.13 ist wohl für Mitte/Ende September erwartet - bis dahin dürfte es auch 3.5.1 vielleich auch schon 3.5.2 geben). Ein MU 3.0.x -> 3.5.0 halte ich für ausgeschlossen.
Versteh zwar immer noch nicht was das mit den en-US builds zu tun hat, aber nun gut, per https://bugzilla.mozilla.org/show_bug.cgi?id=449828#c2 hast du ja eine Antwort erhalten.
Wieso sollte das für en-US nötig sein? Auf der Sprachfassung wird doch entwickelt.
Btw, http://oduinn.com/2009/06/24/no-…l10n-nightlies/
-> Es gibt bald l10n-Nightly-Builds, inklusive inkrementellen *.mars. Unübersetzte Strings werden von en-US bis zur Übersetzung in die jeweilige Sprachfassung übernommen.
