Beiträge von DAC324

Zitat von .Hermes

/*

Wie lange werden solche Konstrukte noch entwickelt ?
Als OOP orientierter Programmierer habe ich dabei riesige Schwierigkeiten.
Ich suche immer den Konstruktor, den Destruktor und saubere Datenabgrenzungen.
*/

Das musst Du Mozilla fragen. Ich für mein Teil wäre ja schon mit einer halbwegs brauchbaren Dokumentation zufrieden. Statt dessen heißt es lapidar "deprecated - refer to [newAPI]". Und zu dem neuen API gibt es höchstens die Interface-Definitionen - kein Wort über benötigte Parameterformate oder Rückgabewerte.

Aber OK. Gibt es denn etwas, das ich bei meiner Flickschusterei hier schon mal verbessern könnte?

Beste Grüße
DAC324

Hallo,

ich hab mich mal durchgewühlt. So sehr viel ist gar nicht geändert worden. Man hat "nur" das API für die "Livemarks" (RSS-Bookmarks) auf asynchronen Betrieb umgestellt, weil man sich davon eine Performanceverbesserung verspricht.

SyncPlaces verwendet ganze zwei der abgekündigten Funktionen: PlacesUtils.livemarks.createLivemarkFolderOnly und PlacesUtils.nodeIsLivemarkContainer.

Leider ist es nicht ohne weiteres möglich, diese Funktionen durch Funktionen aus dem neuen API zu ersetzen:
1. Die neuen Funktionen verlangen ein anderes Parameterformat.
2. Es ist nicht möglich, zusätzliche Funktionen in den Quelltext von SyncPlaces einzubauen. Versucht man das, so geht die interne Referenzierung verloren. Funktionen, die von SyncPlaces selbst definiert werden, werden dann nicht mehr gefunden ("SyncPlacesBookmarks is undefined").

Deshalb musste die Livemarks-Funktionalität abgeschaltet werden.

Läuft hier mit Firefox 23.0.1 ohne irgendwelche Auffälligkeiten

Download hier.

Beste Grüße
DAC324
EDIT: Vergebliche Programmierversuche gelöscht.

Hallo,

Bei mir funktioniert Daniels Seite seit gestern nicht mehr. Ich bekomme einen Timeout. Wie auch immer: Die dort angebotene SyncPlaces-Version verwendet die veraltete Funktion PlacesUtils.livemarks.createLivemarkFolderOnly, welche in Firefox 22 entfernt wurde und deshalb zu einer Fehlermeldung im Addon ("Ungültige oder zerstörte Lesezeichen empfangen") führt. Das Log benennt dann den Übeltäter:

Zitat

PlacesUtils.livemarks.createLivemarkFolderOnly is not a function

Dank der Beiträge hier im Forum weiß ich, dass das alte API schon seit Firefox 6 als "deprecated" gilt und durch mozIAsyncLivemarks ersetzt wird.

Aus diesem Grund habe ich den Aufruf von PlacesUtils.livemarks.createLivemarkFolderOnly in der von mir verlinkten Version geändert auf

id = livemarkService.addLivemark(aLivemarkInfo);

Auf Grund des veränderten Aufrufs dieser Funktion (anderes Parameterformat) mussten noch zwei Variablendeklarationen am Beginn der Funktion importJSONNode eingeführt werden:

var livemarkService = Components.classes["@mozilla.org/browser/livemark-service;2"].getService(Components.interfaces.mozIAsyncLivemarks);
    var aLivemarkInfo = new jsval (node.title, container, index, feedURI, siteURI);

Die so geänderte Version läuft zumindest erst mal ohne Fehlermeldungen durch. Mit Sicherheit sind aber noch weitere Anpassungen notwendig, um wirklich überall auf das aktuelle API umzustellen.

Leider ist die Dokumentation, sagen wir mal, gewöhnungsbedürftig. Deshalb dauert es einige Zeit, für jeden alten API-Aufruf den passenden Ersatz zu finden. Interessant finde ich in dem Zusammenhang, dass Dokumentation für das nicht mehr funktionierende API nach wie vor gepflegt wird:
Places Developer Guide
Last updated by: teoli, Feb 12, 2013 7:00:44 AM Last reviewed by: teoli, Feb 12, 2013 7:00:44 AM
- kein Hinweis darauf, dass das dort genutzte Interface nicht mehr verwendet werden soll (Firefox 6 erschien bereits 2012). Das ist schade, denn dieser Guide ist gut gemacht - eine vergleichbare Dokumentation für mozIAsyncLivemarks habe ich nicht finden können.

Beste Grüße
DAC324

Zitat von Boersenfeger

.. kleiner Hinweis...
Ab Firefox 21 funktionieren diese Erweiterungen nicht mehr...

Zumindest SyncPlaces habe ich wieder zum Laufen bekommen, es funktioniert momentan mit Firefox 23.0.1.

Download hier

Da allerdings noch an vielen Stellen Bezug auf das veraltete API genommen wird, ist noch einiges zu tun, um das Addon wieder dauerhaft einsetzbar zu machen.

Seit langem defekt ist außerdem die Dateikomprimierung in SyncPlaces; außerdem kommt es bei FTP nicht mit transparenten Proxies zurecht, sondern verwendet immer den im Browser eingestellten HTTP-Proxy.

Eine rege Diskussion fand auch bei [url=http://www.daniel-lange.com/archives/71-SyncPlaces,-SortPlaces-...-preserving-these-and-other-excellent-Firefox-add-ons.html]Daniel Lange[/url] statt, aber dessen Seite hat wahrscheinlich jetzt das gleiche Schicksal wie die Addons ereilt - sie ist nicht mehr erreichbar.

Beste Grüße
DAC324

Danke für den Link. Echt coole Sache: Man nimmt all die guten alten Schätzchen jetzt wohl in den Standard auf, die bisher nur proprietär für einzelne Browser anzuwenden waren.

Hab mal ein wenig recherchiert: <embed> war in HTML 4.01 und allen vorherigen Standards tatsächlich nicht enthalten - man sollte statt dessen <object> verwenden. Man ist jedoch zurück gerudert und hat <embed> ebenso wie das in 4.01 als "deprecated" gekennzeichnete <applet> in HTML 5 wieder eingeführt.
Link: http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.5 - <embed> taucht dort nirgendwo auf; <applet> ist klar als "deprecated" gekennzeichnet - taucht aber ebenso wie <embed> kommentarlos in HTML 5 wieder auf.

Hier noch eine Quelle ((C) 2013), wo <embed> als "deprecated" dargestellt wird: http://www.tutorialspoint.com/html/html_deprecated_tags.htm

Schon etwas seltsam, dass man erst als "deprecated" gekennzeichnete Elemente in neueren Versionen wieder kommentarlos einführt. Aber man muss nicht immer alles verstehen

Wie es aussieht, bin ich mit meiner Verwunderung nicht der einzige und auch nicht der erste: http://stackoverflow.com/questions/5972…und-for-a-while - als plausible Erklärung wird auf http://www.w3.org/TR/html-design…ve-the-cowpaths verwiesen.

Mal sehen, sicherlich kommen auch <font> oder gar <blink> spätestens mit HTML 7 wieder zurück

Ach so: Zu der eingangs gestellten Frage, warum der in Firefox eingebaute PDF-Betrachter nicht mit über <embed> eingebundenen PDFs funktioniert, sondern nach wie vor ein externes Plugin benötigt wird, gibt es Bug 738967 - der zwar als "RESOLVED FIXED" gekennzeichnet ist, was aber anscheinend nicht stimmt, wenn ich mir so den letzten Kommentar ansehe

Was für ein Glück, dass es immer jemanden gibt, der es besser weiß

Sicherlich kannst Du dann auch erklären, wie der folgende Text von SelfHTML.org zu verstehen ist (http://de.selfhtml.org/html/multimedi…tm#definieren):

Zitat

In seiner damals Furore machenden Produktversion 2.0 führte Netscape neben anderen bahnbrechenden Neuerungen wie dem font-Element, den Frames und der Möglichkeit, Java-Applets einzubinden, auch ein Element namens embed ein, um andere Multimedia-Inhalte in HTML zu referenzieren. Damit einhergehend implementierte Netscape die so genannte Plugin-Schnittstelle in seinem Browser. Schnell entstand ein Wildwuchs an Plugin-Software, mit deren Hilfe und dem hier beschriebenen Element sich beliebige multimediale oder proprietäre Binärformate in HTML einbinden ließen.

Aus heutiger Sicht gilt für dieses Element jedoch noch stärker als für das Element zum Einbinden von Java-Applets: Es ist ein Relikt und sollte allmählich fallengelassen werden. Denn im Unterschied zum applet-Element hat das embed-Element nie zum HTML-Standard gehört.

Stellt sich trotzdem die Frage: Warum verlangt Firefox für über <embed> eingebundene PDFs trotz internem Viewer immer noch ein extra Plugin? Kann es sein, dass dann wohl an dieser Stelle geschlafen wurde (interner Viewer wird nicht als Plugin erkannt)?

Zitat von Boersenfeger

..wozu noch ein Addon für PDF-Dateien, diese kann FIrefox allein anzeigen....

Leider nicht, wenn <embed> verwendet wird. Viele Super Webmaster befinden sich mit ihrem Bildungsstand leider immer noch im Pleistozän des Webdesigns und lieben Tags, die schon seit Jahrzehnten als "deprecated" gelten:

Beispiel:
<embed src="/ngg/regulatoryContent.do?viewName=PDF&id=168199&File=regDoc.pdf" type="application/pdf" id="pdfReport" height="750" width="95%">

Stößt Firefox auf ein solches Konstrukt, fordert er trotz aktiviertem internen Viewer (PDF.js) ein zusätzliches PDF-Plugin an ("Zusätzliche Plugins sind notwendig...")

Beste Grüße

DAC324

Hallo,

damit dieser Thread nicht vollkommen zur One-Man-Show für "AMG" verkommt, den offenbar außer Java und Flash nichts weiter interessiert, hier mal etwas Neues.

Es gibt endlich ein funktionierendes 64-bit-PDF-Plugin für den Firefox und Derivate! Allerdings liegt es zur Zeit noch in einer Pre-Release-Fassung vor. Aber es funktioniert schon recht gut.

Installation:

• Download der 64-bit-Version des Sumatra PDF Readers von http://xhmikosr.1f0.de/sumatrapdf/
• Programm normal installieren
• Firefox neu starten
• Unter about:plugins nachsehen, ob das "Sumatra PDF Plugin" auftaucht
• Wenn nicht: Die Dateien libmupdf.dll, npPDFViewer.dll und SumatraPDF.exe in das Plugin-Verzeichnis des Firefox kopieren
• Nach Neu Laden von about:plugins sollte das "Sumatra PDF Plugin" angezeigt werden
• Falls es eine Fehlermeldung beim Öffnen von PDFs gibt ("SumatraPDF unaufindbar!") sicher stellen, dass die in Punkt 5 genannten Dateien im Plugins-Verzeichnis liegen
• Fertig! Viel Spaß!

Beste Grüße
DAC324

Hallo,

eine Synchronisationslösung für den eigenen Speicherplatz ohne Bastelei wäre schon was Feines.

Zur Frage der Verschlüsselung bietet SyncPlaces eine Option an, die erzeugte JSON-Datei zu verschlüsseln:
[Blockierte Grafik: http://picsaver.org/thumbs/dkjzrqnyntyjjjjbzyn2.png]

Wie gut diese Verschlüsselung ist, kann ich nicht beurteilen, aber es ist immerhin besser als gar nichts, zumal bei FTP alles im Klartext übertragen wird.

Auf den Quelltext von FTPbox kann man über GitHub zugreifen: https://github.com/FTPbox/FTPbox . Für unixoide Systeme hat es bisher leider nur noch niemand kompiliert...

Beste Grüße
DAC324

Zitat von MoonKid

SyncPlaces verwende ich nicht mehr. Ich sync jetzt direkt die places.sqlite per http://wuala.com (sicherere DropBox-Alternative). So läuft mein FF auf zwei Linux und zwei Windows Rechnern.

Wuala läuft nicht hinter einem Proxy, wenn dieser nicht eine spezielle Form der Authentifizierung unterstützt. Außerdem ist der in Java geschriebene Client mit 28 MB nicht gerade schlank.

Wer einen eigenen FTP-Speicherplatz hat, (z.B. eigener Webspace), kann daher die folgende Lösung ausprobieren.

Benötigt wird ein Programm, welches den Inhalt eines Verzeichnisses in regelmäßigen Abständen mit einem FTP-Server synchronisieren kann. Ich verwende momentan FTPbox.

Man stellt nun SyncPlaces so ein, dass es Bookmarks und Passwörter mit einer lokalen Datei synchronisiert:
[Blockierte Grafik: http://s3.imgimg.de/thumbs/konfig1ffe35e65png.png]
Als Dateipfad gibt man beispielsweise C:\temp\firefox\bookmarks ein:
[Blockierte Grafik: http://s3.imgimg.de/thumbs/konfig2845097dfpng.png]
Wichtig: Komprimierung ausschalten. Diese Funktion scheint in der aktuellen Version von Syncplaces defekt zu sein und führte zumindest bei mir immer zur Fehlermeldung "ungültiger Serverpfad" beim Versuch einer Synchronisation.
[Blockierte Grafik: http://s3.imgimg.de/thumbs/konfig376b7eec5png.png]
Damit die Synchronisierung nicht vergessen wird, kann man Automatikfunktionen in Syncplaces aktivieren. Da jetzt die Synchronisierung mit einer lokalen Datei erfolgt, kommt es auch nicht mehr zu Verzögerungen beim Programmstart bzw. Programmende durch den Verbindungsaufbau.
[Blockierte Grafik: http://s3.imgimg.de/thumbs/konfig4aec338f7png.png]

Nun zur Einrichtung von FTPbox.

Nach dem ersten Start von FTPbox muss man erst mal unter Account die Zugangsdaten zum FTP-Server und das zu synchronisierende lokale Verzeichnis eintragen.

Wichtig ist hierbei, dass man nur das jeweils übergeordnete Verzeichnis angibt, in meinem Beispiel (Bookmarks befinden sich in C:\temp\firefox\bookmarks) also nur C:\temp\firefox. Genau so auch auf dem Server.

Weiterhin sollte man das "Sync Interval" unter "Bandbreite" heraufsetzen. Die Voreinstellung von 10 Sekunden erscheint mir für unseren Zweck etwas zuviel. 600 Sekunden (entsprechend 10 Minuten) reicht sicherlich vollkommen aus.

Damit die automatische Synchronisierung in FTPbox dann auch immer funktioniert, sollte man das Programm unter "Allgemein" so einstellen, dass es mit Windows startet.

Das sollte es gewesen sein. Diese Konfiguration dürfte für alle reichen, die ihre privaten Rechner miteinander synchronisieren möchten, aber normalerweise nur an einem Rechner zur selben Zeit arbeiten.

Beste Grüße
DAC324

Zitat von MoonKid

Im Grunde mache ich mit dem Ding beim Schließen von Firefox ien Backup auf ein von mir gewähltes Verzeichnis meiner lokalen Platte und beim Starten von FF holt er dieses Backup wieder hervor. Das entsprechende Verzeichnis wird allerdings per Wuala (bessere Dropbox Alternative) mit anderen Maschinen gesynct.

Klingt nach einer pfiffigen Lösung. Allerdings kann man das Backup nicht automatisieren, oder doch?

Beste Grüße
DAC324

Der TO sicher nicht, aber vielleicht der eine oder andere, der durch eine Suchmaschine hierher gekommen ist

Hallo,

Ganz einfache Lösung: Tippe about:config in die Adresszeile ein, bestätige die Sicherheitsabfrage. Dann in der obersten Zeile sweetim eingeben und auf die Lupe ganz rechts klicken. Es wird ein Wert namens keyword.URL angezeigt. Rechtsklick auf diesen Wert und "Zurücksetzen" wählen. Fertig!

Beste Grüße
DAC324

Jetzt (bei den aktuellen Nightly Builds) heißt der Befehl about:buildconfig . Man bekommt dann noch ein paar Zusatzinformationen, z.B. über die verwendeten Compilereinstellungen.

Hallo Marco,

ja, ich war auch über die schnelle Reaktion von seiten des Mozilla-Teams erfreut - es gibt jetzt auch bereits einen Nightly Build zum Testen, wo die für das hier diskutierte Verhalten verantwortliche Änderung rückgängig gemacht wurde. Zumindest das Problem mit den Routen bei Google Maps tritt bei dieser Version dann nicht mehr auf.

Die grundsätzliche Ursache für den Fehler scheint folgendes zu sein:

Zitat von Boris Zbarsky (:bz)

Google uses crossOrigin="" all over the place, iirc (which per spec means "Anonymous").

Firefox interpretiert dieses "Anonymous" dann offenbar so, dass versucht wird, die betroffenen Elemente ohne vorherige Authentifizierung am Proxy anzufordern. Wenn ich das also richtig verstanden habe, liegt das dann an Firefox. Es tritt deshalb, wie bereits beobachtet, an jedem Proxy auf, der eine Authentifizierung verlangt, und kann momentan auf Proxy-Seite nur dadurch umgangen werden, dass man die Authentifizierung für diese Elemente abschaltet, was meiner Meinung nach ein ziemlich unschöner Workaround ist.

Beste Grüße
DAC324

Hallo Marco,

vielen Dank für die Rückmeldung. Ich kann das geschilderte Verhalten hier bestätigen. Allerdings ist dabei auch ab und zu mal maps.google.com von den Proxy-Fehlern betroffen. Anbei ein kleiner Ausschnitt (Laden von Google Maps vor der Eingabe einer Route):

[20:55:53.119] GET https://maps.google.com/images/experiments/nav_logo78.png [HTTP/1.1 407 Proxy Authentication Required 0ms]
[20:55:54.991] GET https://maps.google.com/maps/gen_204?imp=ael&jsv=386c [HTTP/1.1 407 Proxy Authentication Required 0ms]
[20:55:56.173] GET https://maps.google.com/maps/gen_204?imp=mapsgl:promo:show&ei=R10DT6zCDM7J_AblwOSlCA [HTTP/1.1 407 Proxy Authentication Required 0ms]

Ich habe jetzt mal einen Bug-Report geschrieben - mal sehen, was da zurück kommt.

UPDATE:
Wie es aussieht, liegt es wirklich nicht an Squid - mit dem Microsoft ISA Server tritt das Problem auch auf, siehe hier.

Beste Grüße
DAC324

Leider habe ich auf die Konfiguration dieses Proxy-Servers keinen Einfluss. Letztendlich bleibt also festzuhalten, dass sich damit der Kreis schließt - offenbar sperren manche Proxies den Firefox beim Laden bestimmter Inhalte aus. Das war ja auch die Frage des Threadstarters. Kann also durchaus sein, dass es an dem eingangs angesprochenen Problem mit der Proxy Authentication liegt.

Damit hat Firefox leider ohnehin immer mal wieder Probleme. Aber das wäre sicherlich ein anderes Thema.
Hier nur so viel:

Ich habe zwar den Firefox so konfiguriert, dass er sich automatisch am Proxy anmeldet (network.automatic-ntlm-auth.trusted-uris, network.negotiate-auth.delegation-uris, network.negotiate-auth.trusted-uris entsprechend ausgefüllt und auch network.automatic-ntlm-auth.allow-proxies auf True gesetzt).
Die meiste Zeit funktioniert das auch ohne Probleme, alle Seiten werden wunschgemäß angezeigt. Hin und wieder aber erscheint das Anmeldefenster für den Proxy - warum, ist nicht nachvollziehbar. Es ist unabhängig von den aufgerufenen Seiten, und es erscheint in unregelmäßigen Abständen, an manchen Tagen gar nicht.
Besonders ärgerlich ist aber, dass diese Anmeldung dann IMMER fehlschlägt (das Fenster erscheint nach Eingabe von Username und Passwort einfach wieder - auch wenn man das richtige Passwort eingegeben hat). Da Proxy und Domain-Server hier in unserem Netzwerk miteinander synchronisiert sind, blockiert man sich nach drei derartigen Versuchen seinen Benutzer-Account, weil der Domain-Server diese fehlgeschlagenen Anmeldungen registriert und nach drei Fehlversuchen die Benutzeranmeldung sperrt.
Das Einzige, was hier hilft, ist im Firefox statt auf "OK" auf "Abbrechen" zu klicken - meistens lädt dann die aufgerufene Seite problemlos.

Beste Grüße
DAC324

Zitat von Boersenfeger

Beim Stichwort "Drittsoftware" sollte man in der Regel an Programme außerhalb von Firefox denken... Z. B. filternde Software

Danke vielmals... der Tipp ging in die richtige Richtung. Hier gibt es einen Proxy, der anscheinend für dieses Verhalten verantwortlich ist. Bei direkter Verbindung ins Internet funktioniert alles wie erwartet.

fragt sich
DAC324

Zitat von .Ulli

Eigentlich sollte jetzt die Suche nach einer störenden Drittsoftware angesagt sein.

Danke für diesen Hinweis. Mich hat nur erstaunt, dass die Änderung des User Agent hier geholfen hat. Ich habe auch schon den Safe Mode ausprobiert - alle Erweiterungen waren dadurch deaktiviert - leider hat das erst mal nichts geholfen.

Beste Grüße
DAC324

Hallo,

das Thema und mögliche Lösungswege wurden auch ausführlich im Trojaner-Board behandelt.

Beste Grüße
DAC324