Bug ist erstellt: https://bugzilla.mozilla.org/show_bug.cgi?id=1762427
Reproducer Add-on werde ich die Tage noch zur Verfügung stellen.
Beiträge von Thunder
-
-
Die Link-Preview-Cards werden in Thunderbird beim "Verfassen" also beim Absender generiert und vermutlich als Teil der dann erzeugten HTML-Mail mit versendet. Beim Empfänger ist dafür überhaupt keine Verbindung notwendig - nur die Anzeige als "Original HMTL", denke ich. Jedenfalls verstehe ich die Beschreibung des Features für Thunderbird so.
-
Ich bin vermutlich über einen Bug gestolpert, der Auswirkungen auf browser.messageDisplay.onMessageDisplayed.addListener(async (tab, message) => { hat. Das event wird nicht für Mails in separaten Windows gefeuert, wenn sich eine Message Property (Junkstatus) ändert. Ursache ist wohl, dass die Message dabei im separaten Fenster gar nicht neu geladen bzw. angezeigt wird. Um dies zu reproduzieren:
Öffne eine HTML-Mail im Original-HTML-Modus im 3-pane-Window (den Preview). Öffne die identische Mail zusätzlich in einem separaten Window, sodass Du beides sehen kannst. Markiere nun die Mail im separaten Window als Junk.
Im 3-Pane-Window wird die Mail neu geladen und der Junk-Button (Main Toolbar und Message Header Toolbar) ändert korrekt seine Anzeige. Im separaten Window wird zwar die gelbe Leiste oben in der Mail eingeblendet, aber die Mail bleibt im originalen HTML angezeigt (wird also nicht neu geladen) und der Junk-Button bleibt unverändert "Junk". Mein Add-on wird dann folglich auch nicht (über die Änderung für das separate Window) informiert, was ich aber benötige.
Das event onMessageDisplayed.addListener(async (tab, message) gibt immer nur die tab.id des 3-pane-Window zurück - auch, wenn ich den Junk-Button im separaten Window benutzt habe, welches eine ganz andere tab.id hat. Das ist irgenwie auch logisch, da die Mail ja scheinbar nur im 3-pane neu geladen wird, aber nicht im separaten Window.
-
Zu Eurer Information:
Ich arbeite derzeit an einer neuen Version des Add-ons, die soweit möglich zu einer MailExtension mit Experiment-APIs umgeschrieben ist. Dabei mache ich derzeit gute Fortschritte, werde aber vermutlich im Verlauf Hilfe von jobisoft benötigen.
-
For both of you Tilo265 and wojtek , the Listener for event "MsgMsgDisplayed" is correctly registered by my addon code, but this (Thunderbird own) event seems never to be "fired", when message were displayed. This event should be fired from Thunderbird itself after every(!) message, which is be displayed.
Do you have an idea, what could be the reason?
-
while the status bar constantly claims that "plain text" view is active
Is it the statusbar text or the checked entry in the statusbar context menu? It may be a part of the main problem or separate problem (if in the context menu).
-
Now for something completely different, Jorg:
was hat es mit Betterbird auf sich?
Soll man das probieren? Besser als TB? Warum?
Dies besprecht Ihr bitte im passenden Unterforum.
-
Version 99 Beta bringt ein paar technische Änderungen mit, die von einer größeren Zahl an Anwendern getestet werden sollten:
-
Sure thing. And if anything happens - provide log from _after_ using AHT - correct?
If possible the complete log out of error console (including Thunderbirds and the Addons startup).
-
Eine Info bezüglich Drucken-Funktion im Anschluss an die Anzeige der Mails mittels "HTML zeigen"-Button:
- Seit Thunderbird 91 funktioniert dies prinzipiell ganz gut, weil der neue Drucken-Dialog dies zufälliger Weise "repariert" hat.
- Wenn man allerdings das Add-on "Printing Tools (NG)" in Thunderbird 91 verwendet, versagt das Drucken mit HTML wieder (genau so wie schon immer mit Allow HTML Temp). Dann muss man doch wieder manuell HTML aktivieren, drucken und manuell wieder zurück auf die eingeschränkte Anzeige der Mails schalten. Der Vorteil des neuen Drucken-Dialogs geht also in Kombination mit den "Printing Tools (NG)" verloren. Daran kann vermutlich auch der Autor der Printing Tools (NG) nichts ändern.
-
Kann die Version aus #28 auch bei NormalUsern die vorherige 7.0 ersetzen?
Ja, es sind lediglich die ganzen console.debug Zeilen nicht auskommentiert und erzeugen somit massenweise entsprechende Einträge/Zeilen in der Fehlerkonsole. Es handelt sich aber ansonsten erstmal identisch um Version 7.0.2, die auf ATN hoffentlich die Tage freigeschaltet wird.
-
-
So I will release this version (without the debug lines) as 7.0.2 on ATN and we'll see, if there will be further reports about the problem.
Would be nice, if you could still be using the debug version (I will provide a new one here).
Thanks -
-
For the debug console entries it is necessary to "use" AHT button "Show HTML", to get the needed console lines.
-
Do the following, please:
1.) Use AHT and send me again the debug lines out of console (the issue is not necessary for this).
2.) Install the following new debug version with some more debug console entries and with some lines changed in code. Use it again and send me the debug lines. Let me know, if the problem is still existing or seems to have gone finally.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist. -
Didn't logs share any information about the issue?
I noticed in your logs that the "MsgMsgDisplayed" listener (which is necessary and actually used to reset the settings at the right moment) is not registered when this should happen. At the moment I don't know the reason for this. But I'm investigating. So far I would probably only think of an improvised workaround, which is somehow unsatisfactory.
-
Das Hauptpasswort sichert letztlich "nur" die einzelnen anderen Passwörter, S/MIME-Zertifikate und OpenPGP-Keys. Das Hauptpasswort kann also theoretisch jederzeit durch ein neues ersetzt werden. Wenn man sich nicht an das alte Hauptpasswort erinnern kann, muss man als Folge davon aber die "anderen" geschützten" Daten haben/kennen bzw. neu eingeben. Die Passwörter zu den einzelnen E-Mail-Konten muss man also auf Dauer kennen bzw. irgendwo "gesichert" haben.
-
Didn't logs share any information about the issue?
Maybe I should create a version with some more/different log entries, to get closer to the problems reason.
-
The screen video is a good idea, but unfortunately I don't see the content of the email, which would be helpful to see the change in display (HTML versus plain text).
Interestingly, after switching to "Plain text" it was OK for a couple of hours and it's back to displaying HTML ("Original HTML in the statusbar, "Plain text" in the context menu selected)
Unfortunately, it is difficult to understand what exactly is happening to you. Is it just an incorrect display of the control element in the status bar at the bottom of the window this time? Or is the HTML mode really still activated (because the automatic switch back to plain text fails) and when selecting and displaying further e-mails, these are then unintentionally displayed with HTML?
