Es ist halt ein "smarter" Workaround für das "Problem", dass an eine noreply-Adresse gesendet wird. Ich denke, dass Tanger eigentlich ein Feature bräuchte und sucht(?), womit die noreply-Adresse einfach aus den Empfängern heraus gelöscht werden könnte. Das wäre doch viel smarter als pur die Warnung zu deaktivieren. Sowas ließe sich bestimmt als Add-on programmieren. Das kann man ja durchaus auch mal als Auftragsarbeit von einem Entwickler machen lassen, wenn man sich das manuelle Löschen der noreply-Adresse sparen möchte.
Beiträge von Thunder
-
-
eine API, die man sich bspw. mit Chrome teilt
Dies ist halt leider eine Einschränkung, die meiner Meinung nach bei Software abseits von Browsern teilweise zu Problemen führt. Die MailExtension-API in Thunderbird hat deshalb ja auch einige Erweiterungen gegenüber der reinen WebExtension-API. Software-übergreifend standardisiert ist die MailExtension-API aber halt noch lange nicht und wird es meiner Vermutung nach auch nie werden.
Theoretisch müsste sich jemand bei MZLA finden, der sich um eine Erweiterung der storage-API bemüht. Ich glaube aber weder an den Willen noch an die Akzeptanz seitens Google oder des Chromium-Projekts(?) für solch eine Erweiterung.
-
an diese Adresse nicht möglich ist
...oder nicht gewünscht ist
Die Absender der noreply@example.com Adressen haben die Möglichkeit einen Reply-To Header anzugeben, in dem eine passende erreichbare Adresse ist. Jedoch ist es häufig so, dass eine Rückmeldung auf die gesendeten Mails in dem Kontext überhaupt nicht erwünscht ist. Wer trotz noreply-Adresse eine Rückantwort "öffentlich" und regelmäßig akzeptiert, macht meiner Meinung nach etwas Konzeptionelles falsch. Ein Bouncing muss deshalb aber nicht unbedingt erfolgen, finde ich.
-
Dieses Add-on speicherte seine Optionen früher als prefs, jetzt aber als "reguläre" Add-on storage. D.h., einmal (aus Versehen) entfernt, alles Optionen weg (danke Mozilla
).Das ist ja keine Erfindung von Mozilla, sondern eine API, die man sich bspw. mit Chrome teilt, denke ich. Die Add-on-Entwickler könnten statt storage.local auch storage.sync verwenden. Dieses speichert nämlich (auch ohne den Sync-Service) die Einstellungen persistent - auch über eine Deinstallation des Add-ons hinaus, wenn ich nicht irre. Es gibt aber halt leider auch eine Menge Anwender, die bei der Deinstallation und anschließenden Neuinstallation von Software (egal ob Thunderbird selbst oder Add-ons) denken, dass alles wieder "neu" und "sauber" sein müsste. Diesem "Verlangen" hat man vermutlich mit storage.local bei dessen Umsetzung nachgegeben. Meiner Vorstellung nach müsste es eine offizielle Variante geben, die zwischen storage.local und storage.sync angesiedelt ist - letztlich sowas wie storage.local.persistent oder ähnlich.
-
Es ist zumindest nichts erkennbar, dass bereits an einer 91.12.1 oder ähnlichem gearbeitet würde. Es gibt im 91er Branch keine Änderungen seit dem 91.12.0 Release.
-
Und was ist oberhalb von "Profiles" so alles?
-
Leute, was soll die Diskussion um die Anzahl der Zeilen oder um die KByte des Codes? Wenn ich im CSS alle möglichen Regeln drin habe, dann erwarte ich zumindest von jemandem wie Boersenfeger, dass er genauer Beschreibt was nicht funktioniert und um welche CSS Rule es sich dabei handelt, die nicht funktioniert. Es kann natürlich theoretisch auch sein, dass alle Rules aus dem gezeigten CSS nicht mehr funktionieren. Aber auch dies könnte man vielleicht etwas differenzierter als Problem beschreiben.
-
Letztlich entscheidend bei der Diskussion hier und im parallelen Thema ist, dass Boersenfeger wohl dafür kritisiert wird, dass er zu viel CSS-Code zur Diskussion stellt, bei dem man gar nicht überblicken kann was nun funktioniert und was nicht. Es wäre also nett, wenn man jeweils "nur" den relevanten Teil des CSS zur Diskussion stellt.
-
Vielleicht ist dies dieser Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1777913
-
Am einfachsten wäre es, den ImapMail-Ordner komplett zu löschen.
Dies könnte demnächst (wieder) funktionieren. Ab dem heutigen Daily-Build wird der komplette ImapMail-Ordner von Thunderbird wieder neu erstellt, wenn man diesen gelöscht oder verloren hatte. Dass dies zuvor nicht funktioniert hat, war eine Regression durch einen anderen Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1777937
-
Bei Deinem ursprünglichen (ersten) Beitrag habe ich die toten Links heraus gelöscht. Für die Bilder in Deinem weiteren Beitrag bis Du alleine verantwortlich. Falls Du zuvor die Bilder noch im ersten Beitrag sehen konntest, dann lag dies an dem von mir genannten Cache, auf den nur Du zugriff hattest und somit die Bilder dort noch sehen konntest. Das ist ein (eigentlich behobenes) Problem der Foren-Software, wenn man einen Reload beim Erstellen des Beitrags macht, bevor dieser wirklich final abgesendet wurde. Die Bild-Dateien (Dateianhänge) werden dann nämlich in Wahrheit gar nicht an den Server übertragen, sondern sind nur in einem Cache auf Deinem PC / Mac vorhanden.
-
Ich würde wetten, dass Du eine userChrome.css verwendest, in der es Anpassungen gibt, oder?
-
Kleine technische Rückfrage: Hast Du beim Erstellen des Foren-Themas bzw. Beitrags einen "Reload" im Browser gemacht, nachdem Du den Dateianhang (das Bild) hochgeladen hast, aber noch bevor Du den Beitrag final abgesendet hast? Das hat nämlich vermutlich zum Verlust des Dateianhangs geführt (den Du dennoch zunächst noch in Deinem Browser aus einem Cache heraus sehen konntest).
-
Der von mir genannte Ordner liegt in der Regel trotz ausgelagertem Profil genau dort, wo ich ihn gezeigt habe.
Hat denn irgendwer von den inzwischen 3 beteiligten Hilfesuchenden meinen Tipp ausprobiert, statt nur zu sagen, dass er/sie auch das Problem hat?!
%LocalAppData%\Thunderbird\
Danke Dir für den passenden Shortcut, den man per Windows-Suche bzw. "Ausführen"-Funktion unter Windows aufrufen kann. Das ist genau das Verzeichnis, welches man guten Gewissens einfach löschen kann, weil es (trotz eines Unterordners mit dem Namen "Profiles") eben nicht die relevanten persönlichen Profil-Daten enthält, sondern nur bestimmte quasi Cache-Daten.
-
juergenz hat ja wohl grundlegend schon das "passende" Problem. Insofern verstehe ich schon, dass er sich in das Thema eingeklinkt hat, was für mich bis hier hin okay ist. Für mich geht es dann aber zu weit, wenn plötzlich sein Beitrag die Basis für eine Diskussion um den Ort von bestimmten Profil-Daten sorgt, was im Prinzip Drachen angestoßen hat.
-
-
Wer schreibt Dir mit "noreply@...", der darauf eine Antwort erhalten will und diese auch tatsächlich liest? Und wieso kommt sowas scheinbar regelmäßig vor, sodass ein Abschalten des Features tatsächlich relevant für Dich sein kann? Meine Rückfrage ist natürlich unbequem, aber manchmal sind auf Dauer andere Lösungsansätze zielführender.
-
Ich habe den Beitrag anonymisiert (E-Mail-Adressen) und außerdem das angehängte PDF gelöscht, da dieses ebenfalls voll mit den privaten Daten war.
1.) Bitte anonymisiere alle Texte und Bilder
2.) Stell den anonymisierten Text und die anonymisierten Bilder hier direkt in Deinen nächsten Beitrag. Verzichte dabei auf das PDF.
-
wie willst du dann auch nur halbwegs vernünftig arbeiten?
Eine berechtigte Frage
-
In der Version TB 78 wird der Konten-Assistent noch nicht in einem Tab
Ich sprach nicht vom Assistenten, sondern von dem Tab mit den Konten-Einstellungen. Dies ist auch in 78 schon ein Tab. Meine Frage zielte darauf ab, ob man es hinbekommen könnte dort hinzugelangen und dann dort erfolgreich das Konto fertig einzurichten, wenn man den Assistenten vorher mittendrin abwürgt. Dazu müsste man aber dennoch den Assistenten erstmal ein Stück weit nutzen, was womöglich mittels Alt + passendem Accesskey möglich wäre.
An die Auflösung habe ich auch schon gedacht. Vielleicht könnte man die versteckte Pref layout.css.devPixelsPerPx missbrauchen, wenn man diese auf ungefähr 0.8 oder 0.7 stellt.
