Beiträge von Thunder

Deine Lösung mag funktionieren, auch wenn ich momentan erstmal nur eine grobe Vorstellung von "original" und "current" habe.

Wenn wir jetzt aber mal die Realität betrachten, dann ist es doch so, dass circa 10.000 Anwender (oder Installationen) das Add-on verwenden. Diese Zahl hat sich seit langer Zeit kaum verändert. Aus rein technischer, formaler, Support und vielleicht auch "sportlicher" Sicht, kann man das alles einbauen. Es wird aber der stabilen User-Basis von rund 10.000 gar nichts bringen, da deren "original" Werte aus Add-on-Sicht gar nicht mehr zu eruieren sind.

Zitat von jobisoft

Ne andere Lösung fällt mir derzeit nicht ein.

Mir schon...

1. siehe oben: Dialog beim Deaktivieren/Deinstallieren des Add-ons

2. Das Add-on verändert nur auf Wunsch des Users Einstellungen. Der User könnte er im Text der Add-on-Dialogtexte darauf hingewiesen werden, dass es sich um Einstellungen handelt, die er in Thunderbird zurücksetzen könnte.

Ich baue es jetzt so ein, wenn es klappt:

1. Im Optionen-Dialog wird es zwei Reset Buttons geben: einer zu Default, und einer zu Recommended
2. Beim Shutdown wird ein Dialog fragen, ob zu Thunderbirds defaults zurückgekehrt werden soll (HTML-Modus, Inline-Attachments und Remote Content)

Schritt 1 ist erledigt:

Zitat von jobisoft

Daher die Bitte: Speichere den Zustand aller prefs die du dauerhaft änderst und reverte auf diesen Zustand, wenn den add-on runterfährt.

Das kann ich prinzipiell gerne machen, aber:

• Was ist, wenn andere Add-ons ebenfalls die gleichen Prefs nutzen und/oder verändern? Denen pfusche ich dann unerwartet ins Handwerk.
• Was ist, wenn der Benutzer bewusst die Pref im Add-on oder in Thunderbirds eigener UI verändert hat? Dann überschreibe ich auch wieder dessen gewählte Einstellung.

Technisch könnte ich theoretisch bei der Installation des Add-ons die relevanten Prefs im local storage hinterlegen und von dort bei der Deinstallation/Deaktivierung wieder in die Prefs zurück schreiben. Aber die Fragen bleiben dabei offen und problematisch. Ich könnte sogar per Listener Änderungen an den Prefs mitbekommen, um diese für später auch zu berücksichtigen. Nur leider wird dies scheitern, da der Listener ja gar nicht unterscheiden kann, ob in den Optionen des Add-ons umgeschaltet wurde oder in Thunderbirds Benutzeroberfläche.

Immerhin "manipuliert" mein Add-on erstens nur zugängliche Prefs, und hinterlässt auch da nur Veränderungen, wenn diese mehr oder minder bewusst vom Anwender im Dialog vorgenommen wurden. Alles was im Hintergrund temporär abläuft, hinterlässt keine Veränderungen an den Prefs.

Ich hatte außerdem extra den "Reset" Button im Dialog eingebaut, um zu sicheren Einstellungen zurückkehren zu können. Dies dann aber wenigstens bewusst für den Anwender. Bei diesem Reset müsste ich dann halt "Anhänge immer eingebunden anzeigen (nicht empfohlen)" eigentlich aktivieren, da dies Thunderbirds default ist. Momentan (Version 8.0a5 des Add-ons) wird die Option beim Reset deaktiviert.

Edit:

Was man natürlich machen kann: Bei der Deinstallation müsste ein Dialog alle Einstellungen beim Anwender erfragen, wie er diese denn gerne haben möchte.

Im gelben "Doorhanger" mit dem Kontextmenü für externe Inhalte ("remote content") wird vom Add-on das oncommand per experimenteller API überschrieben (mehr oder minder entfernt) und mittels eines eventlisteners abgefangen, um an der Stelle bei installiertem Add-on nach dem Klick auf "HTML zeigen" dann auch das vom Anwender erwartete Verhalten beim Klick auf "Externe Inhalte in dieser Nachricht anzeigen" zu bewirken (es muss dann nämlich für den Reload mit externen Inhalten nochmals temporär HTML erlaubt werden).

Dieses oncommand wird beim Shutdown des Add-ons in der experimentellen API zurück gesetzt:

onShutdown(isAppShutdown) {
  if (isAppShutdown) {
    return; // the application gets unloaded anyway
  }

  ExtensionSupport.unregisterWindowListener(
    tracker.windowListenerId,
  );

  for(let window of tracker.trackedWindows) {
    // console.debug("AHT - onShutdown");
    let element = window.document.getElementById("remoteContentOptionAllowForMsg");
    element.removeEventListener("click", tracker.notifyOnClickedListener);

    let oncommand_original = "LoadMsgWithRemoteContent();";
    element.setAttribute("oncommand", oncommand_original);
  }

  // Flush all caches
  Services.obs.notifyObservers(null, "startupcache-invalidate");
}

Hallo Leute!

Ich möchte dieses Thema hier mal eröffnen und nutzen, um Euch nochmals über die Funktion von Allow HTML Temp (im Folgenden: AHT) aufzuklären.

Der Wunsch von jobisoft hat mir gezeigt, dass vermutlich viele Anwender das Prinzip von AHT nur bedingt verstehen, denn ein Zurücksetzen von Thunderbirds eigenen Prefs ist aus meiner Sicht gar nicht notwendig:

Zitat

Code

*********
John Bieling wrote:

With your next version, could you return to a standard pref configuration, when your add-on is shutting down?

*********

Die Optionen meines Add-ons:

Die Standard-Einstellung wechselt den HTML-Modus ganz genau so, wie es auch Thunderbirds eigener Menüpunkt Ansicht → Nachrichteninhalt macht. Daran gibt es nichts zurückzusetzen.

Klick auf "HTML zeigen" ist ein Teil der Einstellung für die Funktion des Buttons des Add-ons. Wenn der Button genutzt wird, wird die vorherige HTML-Einstellung (also die notwendigen Prefs dazu) kurz zwischengespeichert und sobald die Nachricht dann mit der gewünschten Einstellung angezeigt wurde (dies wird mit einem "event listener" erkannt), werden die Prefs aus dem Zwischenspeicher im Hintergrund sofort wieder hergestellt. Daran gibt es also später auch nichts mehr zurückzusetzen.

Externe Inhalte in Nachrichten global erlauben ist die identische Einstellung, die man in Thunderbirds Einstellungen-Dialog findet:

Genau diese Einstellung wird also umgeschaltet. Daran gibt es auch nichts zurückzusetzen. Der Anwender kann dies jederzeit in Thunderbirds Einstellungen machen.

Bei Klick auf "HTML zeigen" für die eine Nachricht erlauben ist wieder ein temporäres aktivieren der Pref, deren vorheriger Zustand zwischengespeichert wird und dann sofort wieder hergestellt wird.

Anhänge immer eingebunden anzeigen (nicht empfohlen) ist wieder eine Pref von Thunderbird selbst, die man in Thunderbird über das Menü Ansicht → Anhänge eingebunden anzeigen ebenfalls identisch schalten kann. Auch daran gibt es eigentlich nichts zurückzusetzen.

Bei Klick auf "HTML zeigen" temporär eingebunden anzeigen ist wieder ein temporäres aktivieren der Pref, deren vorheriger Zustand zwischengespeichert wird und dann sofort wieder hergestellt wird.

Später bei der Deinstallation meines Add-ons gibt es also aus meiner Sicht keine Thunderbird-eigenen Prefs, welche dann noch zurückgesetzt werden könnten oder müssten. Die kurzzeitig ("temporär") manipulierten Prefs wurden alle immer wieder sofort zurück gesetzt. Die restlichen Prefs sind letztlich Einstellungen, die das Add-on wegen des thematischen Zusammenhangs in seinem Optionen-Dialog mit anbietet. Diese Einstellungen sind aber ganz normal über die Benutzeroberfläche des Thunderbird sowieso vorhanden und können dort auch jederzeit (egal ob mit oder ohne Add-on) umgeschaltet werden. Das Add-on berücksichtigt dies auch jederzeit. Würde man bei der Deinstallation des Add-ons nun noch etwas zurücksetzen wollen, muss die Frage gestellt werden, was man dann überhaupt noch zurücksetzen will. Der Anwender könnte nämlich während der Nutzungszeit des Add-ons über Thunderbirds eigene Benutzeroberfläche diese Einstellung verändert haben. Die sollen dann gar nicht unerwartet zurückgesetzt werden.

Alle Einstellungen, die das Add-on selbst betreffen sind ab Version 8 des Add-ons im "local storage" abgelegt und werden bei Deinstallation des Add-ons entfernt, so wie es eben für WebExtensions üblich ist. So lange das Add-on keine Fehlfunktionen hat, hinterlässt es auch keine durcheinander gebrachten Prefs des Thunderbird. Und selbst wenn dies (für den HTML-Modus) passieren würde, dann muss der Anwender nur einmal über Ansicht → Nachrichteninhalt umschalten und alles ist wieder durch Thunderbird selbst korrigiert, da dieser dabei die Prefs selbst (dann korrekt) überschreiben würde.

Ich hoffe hiermit etwas Licht ins Dunkel zu bringen. Ihr könnt aber gerne auch fragen. Ich kann im Zweifelsfall auch im Code die Dinge erklären.

Zitat von Susi to visit

Wenn das Problem im Fehlerbehebungsmodus nicht auftritt, dann ist der Verursacher sehr wahrscheinlich eine Erweiterung etc.

Naja, Thunderbird deaktiviert auch ein paar eigene Dinge im Fehlerbehebungsmodus, die für den Anwender (und auch für mich) undurchsichtig sind.

Das Problem bezüglich mail.db.idle_limit wurde ursprünglich hier beschrieben: https://bugzilla.mozilla.org/show_bug.cgi?id=794401

Das Problem kam wohl mit Thunderbird irgendwo bei Version 15-17 auf und wurde theoretisch für die meisten (aber nicht alle) Anwender mit Thunderbird 38 behoben.

Das Problem besteht wohl (nur?) bei Anwendern mit über 30 (?) Ordnern. Vermutlich spielt die Größe bzw. Anzahl der Mails pro Ordner auch eine Rolle. Und dann spielt sicherlich die Performance des PCs und des verwendeten Datenträgers auch eine Rolle. Es könnte beispielsweise sein, dass Anwender mit einer SSD davon viel weniger bemerken. Auswirkungen hat das Problem beispielsweise für Nutzer von Notebooks, wenn deren Akku leer gesaugt wird - ganz unabhängig davon, ob man beim Arbeiten selbst Wartezeiten bemerkt.

Es gab auch diesen Bug mit Anleitung bezüglich Debugging: https://bugzilla.mozilla.org/show_bug.cgi?id=1388696

Ich denke, der relevante offene Bug dazu ist jetzt dieser: https://bugzilla.mozilla.org/show_bug.cgi?id=1305207

Zitat von Waynes Comment on Rainbow Chard

As of version 38, most issues involving mail.db.idle_limit should be resolved. (This blog was published Feb 2013, roughly in the time period of Thunderbird 17.) However, as recent comments indicate, there may still be unresolved issues. We, the Thunderbird community, want to fix them.

If you did the workaround of setting mail.db.idle_limit, please reset mail.db.idle_limit to it’s default value; see if you can reproduce the problem with default settings.

Anyone having a performance issue – please file a bug report with the details at https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird Thanks for helping us improve Thunderbird.

A very breif history:

* https://bugzilla.mozilla.org/show_bug.cgi?id=723248 circa Sept 2012 delivered a method of closing “idle folders” (message databases) using mail.db.idle_limit and mail.db.max_open

* https://bugzilla.mozilla.org/show_bug.cgi?id=793455 quickly fixed a resulting bad performance issue in version 16

* Somewhat later, a remaining issue was found and fixed roughly June 2015 in version 38 https://bugzilla.mozilla.org/show_bug.cgi?id=1135310

Alles anzeigen

Standard für mail.db.idle_limit ist in Thunderbird 91 derzeit 300000 Millisekunden (also 1000 * 60 * 5), was 5 Minuten entspricht.

In folgendem Artikel steht vieles drin:

E-Mail-Konto (IMAP) einrichten - Thunderbird Mail DE

Die Screenshots sind leider immer wieder schneller veraltet als einem lieb ist, aber sinngemäß sollte man alles am aktuellen Thunderbird erkennen können.

Zitat von jobisoft

Was die Sache etwas kompliziert macht: Alle action buttons aller tabs/windows sind gleich. Es gibt einen bug der individuelle Eigenschaft vorschlägt, hab da aber noch nicht reingeschaut. Das haben wir von Firefox geerbt.

Das ist in meinem Fall kein Problem. Momentan sind beide Buttons ja sowieso identisch. Das Icon des momentan identischen Buttons zeigt, welche Einstellung man für die "temporäre" Funktion des Buttons gewählt hat. Dies gilt in allen Fenstern.

Das Statusleisten-Element hatte bisher mit den unterschiedlichen Icons gezeigt welcher HTML-Modus für Thunderbird selbst gerade gewählt ist. Dies gilt ja auch für alle Fenster.

Mit den UTF-Icons könnte ich tatsächlich mal experimentieren. Glücklich würde mich wahrscheinlich letztlich nur machen, wenn Elemente (Icon + Text) für die Statusleiste in Zukunft dann doch mal per MailExtension-API möglich werden.

Zitat von jobisoft

Der action button ist in stand allone message windows nicht vorhanden

Deswegen ist der messageDisplayAction-Button für die zentrale Funktion notwendig. Ich habe also aus meiner Sicht nur den browserAction-Button, den ich abwandeln könnte für die Status-Anzeige - zumal eine einfache Umschalt-Möglichkeit hin und wieder gewünscht ist. Dafür gibt es sogar ein separates Add-on, welches aber den Status nicht "live" anzeigen kann. Die "live"-Anzeige per Listener wäre mir aber wichtig, um dem Anwender keinen falschen Status vorzugaukeln.

Zitat von jobisoft

Du könntest eine badge für den status benutzen

Badge kann AFAIK nur 3 Buchstaben und ist von meinen Tests her extrem hässlich an den Buttons. Außerdem überdeckt das Badge dann wieder einen Teil des Icons, wenn ich nicht irre.

Zitat von Mailhacker

Gibt es noch irgendwelche Optimierungen für Thunderbird die für mich auch empfehlenswert wären.

Bestimmt jede Menge - nur ist meine Glaskugel gerade im Standby

Im überarbeiteten Add-on fehlt jetzt noch die Anzeige des HTML-Status, welche man bisher unten in der Statusleiste sehen (und umschalten) konnte. Direkt in der Statusleiste ist dies bisher mit WebExtension-Code nicht möglich. Ich möchte dafür auch keinen weiteren Code in einer Experiment-API nutzen - dies sollte auf das wirklich zentral Notwendige beschränkt bleiben, denke ich.

Ich hätte eine Idee, wie man das Problem lösen könnte:

Den bisherigen AHT-Button gibt es im Grunde doppelt, da dieser sowohl in der Haupt-Symbolleiste als auch in der Kopfzeilen-Symbolleiste vorhanden ist. Man könnte den Button aus der Haupt-Symbolleiste entfernen und statt dessen dort einen neuen Button "HTML-Modus" einbauen. Dieser Button könnte dann wieder mittels der verschiedenen Icons (farbig, grau oder schwarz-weiß) den Status der HTML-Einstellung zeigen. Außerdem könnte dieser neue Button ein Popup-Menü bieten, worin man den HTML-Modus dann manuell umschalten kann. Damit wäre alles erfüllt, was bisher das Element in der Statusleiste unten geboten hatte. Allerdings ist der "browserAction"-Button (so nennt der sich im WebExtension-Code) für die Hauptsymbolleiste nur im 3-Pane-Window verfügbar, wenn ich nicht irre. Übrigens sind per WebExtension leider keine 2 (oder mehr) Buttons mehr möglich, die man für die Symbolleisten anbieten könnte. Es geht also jeweils nur noch ein Button pro Symbolleiste.

Ein "Mockup" der Idee:

[mark]Ich kann Eure Meinungen und Ideen diesbezüglich gebrauchen![/mark]

Zitat von Mailhacker

Ordner Namens DRAFTS(1)

Das sieht doch typisch nach einer Art Duplikat eines Ordners aus. Wenn es schon "Drafts" gibt, wird das Duplikat dann halt als "Drafts(1)" oder irgendwann "Drafts(999)" bezeichnet. Auf der Festplatte heißt Thunderbirds Entwürfe-Ordner "Drafts" und wird in der Oberfläche des Programms dann auf Deutsch als "Entwürfe" angezeigt. Diese deutsche Benennung erfolgt aber nur, wenn Thunderbird selbst den Ordner als diesen speziellen Ordner auch (ich sage mal) anerkennt - dann hat der Ordner auch das spezielle Icon.

Ein Grund für ein plötzliches Duplikat des Ordners auf dem Datenträger (in Wahrheit ja vermutlich eine Mbox-Datei) könnte sein, dass die Mbox-Datei vorübergehend blockiert wurde oder beschädigt wurde.

Ich habe jetzt einen Shortcut für das Umschalten zwischen angezeigten Zitaten und kollabierten Zitaten eingebaut: Alt+Q

Das Tastaturkürzel funktioniert, wenn die Kollabieren-Funktion in den Optionen des Add-ons eingeschaltet ist. Bisher kann man allerdings nur absolut alle Zitate ausblenden oder alle Zitate einblenden.

Ihr braucht dafür Version 3.2.4 des Add-ons, damit es korrekt funktioniert.

Zugehöriger Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1757713

Zitat von o0Julia0o

Ist Thunderbird solch ein sicheres Programm? Also kann ich damit weiterhin E-Mails abrufen?

Thunderbird ab Version 91.8.0 wird nahtlos weiter mit Google funktionieren. Wenn bisher nicht geschehen, wird das OAuth2-Login präsentiert. Wichtig ist, dass man Cookies in Thunderbird nicht verboten hat - diese sind für OAuth2 notwendig.

Zitat von Susi to visit

sondern über das WLAN der Klinik?

Die Frage würde ich noch präzisieren: Handelt es sich um ein WLAN, welches von der Klinik betrieben wird, oder handelt es sich um einen Telekom-Hotspot?

Funktion technisch weiter verbessert und nun auch wieder das Nachladen der externen Inhalte über das Kontextmenü im "Doorhanger" funktionierend eingebaut.

Danke jobisoft

allow-html-temp_8.0a5.xpi

Zitat von dErzOnk

ich habe das nämlich nicht in der Meldung bei Google lesen können... sondern nur das "Passwort normal/verschlüsselt" nicht mehr möglich sein wird

Kann sein, dass ich dies falsch verstanden hatte:

Zugriff auf Ihr Google-Konto durch weniger sichere Apps - Google-Konto-Hilfe

Google erlaubt das Login mit den App-Passwörtern ab Ende Mai nicht mehr. Thunderbird migriert das Login deswegen nun zu OAuth2 - dafür sind Cookies notwendig.

Zitat von milupo

ich hätte da Obersorbisch (hsb) und Niedersorbisch (dsb)

Danke, habe ich gerade eingebaut!