Firefox weigert sich seit kurzem eine pdf Datei herunterzuladen
Hallo Liste, mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen. Normal ist bei mir eingestellt, dass FF immer fragen soll, was mit der PDF geschehen soll (anzeigen mit okular oder speichern). Nun kommt die Meldung: problem mit Firefox beim laden einer PDF /home/herbert/Downloads/3QJP9Q- n.pdf.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator. Kann mir jemand einen Tipp geben, wie ich das wieder abstelle? Diese Feature Muss wohl mit den letzten FF Updates reingekommen sein. In falkon wird das korrekt ausgeführt. Gruß Herbert
Am 29.10.24 um 15:12 schrieb Herbert Albert:
Hallo Liste,
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen.
Eine bestimmte oder alle? Wie ist es denn mit dieser hier: http://www.download.schweich.de/Amtsblatt_PDF/2024/KW_04_Schweich.pdf Hier, und mit firefox 128.3.1esr, funktioniert das normal. Eingestellt ist, dass das File im FF-internen PDF Viewer angezeigt wird, wenn nötig, lade ich sie von dort aus herunter. -- Viele Grüße Michael
Am Dienstag, 29. Oktober 2024, 15:32:47 CET schrieb Michael Behrens:
Am 29.10.24 um 15:12 schrieb Herbert Albert:
Hallo Liste,
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen.
Eine bestimmte oder alle? Wie ist es denn mit dieser hier:
http://www.download.schweich.de/Amtsblatt_PDF/2024/KW_04_Schweich.pdf
Hier, und mit firefox 128.3.1esr, funktioniert das normal. Eingestellt ist, dass das File im FF-internen PDF Viewer angezeigt wird, wenn nötig, lade ich sie von dort aus herunter. bei allen PDFs. Wenn ich auf den FF-Viewer schalte funktioniert es auch bei mir, aber das will ich nicht. Stell doch bei Dir mal um, ob Du dann auch das Problem hast.
Hallo Herbert,
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen.
Eine bestimmte oder alle? Wie ist es denn mit dieser hier:
http://www.download.schweich.de/Amtsblatt_PDF/2024/KW_04_Schweich.pdf
Hier, und mit firefox 128.3.1esr, funktioniert das normal. Eingestellt ist, dass das File im FF-internen PDF Viewer angezeigt wird, wenn nötig, lade ich sie von dort aus herunter. bei allen PDFs. Wenn ich auf den FF-Viewer schalte funktioniert es auch bei mir, aber das will ich nicht. Stell doch bei Dir mal um, ob Du dann auch das Problem hast.
Funktioniert unter Leap 15.6 mit 128.3.1esr (64-Bit) ganz normal → Auswahl anbieten und herunter laden. Woher hast Du die Version 132.0 von Firefox? Gruß Robert -- Homepage: https://www.familiegrosskopf.de/robert
Am Dienstag, 29. Oktober 2024, 17:00:34 CET schrieb Robert Großkopf:
Hallo Herbert,
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen.
Eine bestimmte oder alle? Wie ist es denn mit dieser hier:
http://www.download.schweich.de/Amtsblatt_PDF/2024/KW_04_Schweich.pdf
Hier, und mit firefox 128.3.1esr, funktioniert das normal. Eingestellt ist, dass das File im FF-internen PDF Viewer angezeigt wird, wenn nötig, lade ich sie von dort aus herunter.
bei allen PDFs. Wenn ich auf den FF-Viewer schalte funktioniert es auch bei mir, aber das will ich nicht. Stell doch bei Dir mal um, ob Du dann auch das Problem hast.
Funktioniert unter Leap 15.6 mit 128.3.1esr (64-Bit) ganz normal → Auswahl anbieten und herunter laden.
Woher hast Du die Version 132.0 von Firefox?
Gruß
Robert -- Homepage: https://www.familiegrosskopf.de/robert
Hallo Robert, mein FF komt aus dem mozilla Repo https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/[1] Was ich nun festgestellt habe, als ich die Repo-Daten aufmachen wollte (hier sollte nedit geöffnet werden), dass es auch mit anderen Dateien als pdf klemmt. /home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte. Versuchen Sie es später erneut oder kontaktieren Sie den Server-Administrator. Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF. Gruß Herbert -------- [1] https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/
Am Dienstag, 29. Oktober 2024, 17:32:19 CET schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 17:00:34 CET schrieb Robert Großkopf:
Hallo Herbert,
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen.
Eine bestimmte oder alle? Wie ist es denn mit dieser hier: http://www.download.schweich.de/Amtsblatt_PDF/2024/KW_04_Schweich.p df
Hier, und mit firefox 128.3.1esr, funktioniert das normal. Eingestellt ist,
dass das File im FF-internen PDF Viewer angezeigt wird, wenn
nötig, lade ich sie von dort aus herunter.
bei allen PDFs. Wenn ich auf den FF-Viewer schalte funktioniert es auch bei
mir, aber das will ich nicht. Stell doch bei Dir mal um, ob Du dann
auch das Problem hast.
Funktioniert unter Leap 15.6 mit 128.3.1esr (64-Bit) ganz normal → Auswahl anbieten und herunter laden.
Woher hast Du die Version 132.0 von Firefox?
Gruß
Robert
Hallo Robert,
mein FF komt aus dem mozilla Repo https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/[1]
Was ich nun festgestellt habe, als ich die Repo-Daten aufmachen wollte (hier sollte nedit geöffnet werden), dass es auch mit anderen Dateien als pdf klemmt.
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server-Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Gruß
Herbert
-------- [1] https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/ habe im www diese Seite https://www.reddit.com/r/firefox/comments/16ou02v/only_downloading_part_files/?tl=de[1] gefunden. Doch der Tipp hilft bei mir nicht. habe nun auch probehalber $HOME/.mozilla umbenannt und den aus der letzten Sicherung installiert. Hilft auch nicht.
-------- [1] https://www.reddit.com/r/firefox/comments/16ou02v/only_downloading_part_file...
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist. -- MfG Richi
Am Dienstag, 29. Oktober 2024, 19:25:31 CET schrieb Richard Kraut:
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist. auf $HOME ist noch Platz, an den Rechten hat sich nichts geändert und falkon und Vivaldi tun genau das, was FF bis vor kurzen auch getan hat. Entweder fragen, oder mit der Endung zugeordneter Applikation starten.
Was in FF geht ist, dass ich in den Einstellungen sage z. B. pdf mit der Systemstandardanwendung (okular) öffnen oder *.repo mit "Mit nedit öffnen". Kann man machen, aber dann fehlt mir die Wahlmöglichkeit mal was anderes zu machen. Gruß Herbert
Am Dienstag, 29. Oktober 2024, 19:50:22 CET schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:25:31 CET schrieb Richard Kraut:
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist.
auf $HOME ist noch Platz, an den Rechten hat sich nichts geändert und falkon und Vivaldi tun genau das, was FF bis vor kurzen auch getan hat. Entweder fragen, oder mit der Endung zugeordneter Applikation starten.
Was in FF geht ist, dass ich in den Einstellungen sage z. B. pdf mit der Systemstandardanwendung (okular) öffnen oder *.repo mit "Mit nedit öffnen". Kann man machen, aber dann fehlt mir die Wahlmöglichkeit mal was anderes zu machen.
Gruß
Herbert habe noch ein bisschen rumprobiert. Scheint mit allen Dateiendungen zu sein, bei denen "Jedes Mal nachfragen" gewählt wurde. Und bei euch ist das nicht der Fall?
Am 29.10.24 um 19:55 schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:50:22 CET schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:25:31 CET schrieb Richard Kraut:
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist.
auf $HOME ist noch Platz, an den Rechten hat sich nichts geändert und falkon und Vivaldi tun genau das, was FF bis vor kurzen auch getan hat. Entweder fragen, oder mit der Endung zugeordneter Applikation starten.
Was in FF geht ist, dass ich in den Einstellungen sage z. B. pdf mit der Systemstandardanwendung (okular) öffnen oder *.repo mit "Mit nedit öffnen". Kann man machen, aber dann fehlt mir die Wahlmöglichkeit mal was anderes zu machen.
Gruß
Herbert habe noch ein bisschen rumprobiert. Scheint mit allen Dateiendungen zu sein, bei denen "Jedes Mal nachfragen" gewählt wurde. Und bei euch ist das nicht der Fall?
Hi, ich lade immer die Updates von Mozilla selbst runter. Komischerweise hat er mich (noch?) nicht auf das 132er Update hingewiesen, aber ich habe den 132er jetzt installiert und PDF auf "jedes Mal fragen" gesetzt... macht er problemlos. Ich kann zwischen öffnen, öffnen mit Anwendung und Speichern wählen, und was ich wähle, wird auch ausgeführt. Also am Mozilla-FF kann es nicht liegen... -- cu jth
Am Mittwoch, 30. Oktober 2024, 07:33:38 CET schrieb Jörg Thümmler:
Am 29.10.24 um 19:55 schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:50:22 CET schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:25:31 CET schrieb Richard Kraut:
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist.
auf $HOME ist noch Platz, an den Rechten hat sich nichts geändert und falkon und Vivaldi tun genau das, was FF bis vor kurzen auch getan hat. Entweder fragen, oder mit der Endung zugeordneter Applikation starten.
Was in FF geht ist, dass ich in den Einstellungen sage z. B. pdf mit der Systemstandardanwendung (okular) öffnen oder *.repo mit "Mit nedit öffnen". Kann man machen, aber dann fehlt mir die Wahlmöglichkeit mal was anderes zu machen.
Gruß
Herbert
habe noch ein bisschen rumprobiert. Scheint mit allen Dateiendungen zu sein, bei denen "Jedes Mal nachfragen" gewählt wurde. Und bei euch ist das nicht der Fall?
Hi,
ich lade immer die Updates von Mozilla selbst runter. Komischerweise hat er mich (noch?) nicht auf das 132er Update hingewiesen, aber ich habe den 132er jetzt installiert und PDF auf "jedes Mal fragen" gesetzt... macht er problemlos. Ich kann zwischen öffnen, öffnen mit Anwendung und Speichern wählen, und was ich wähle, wird auch ausgeführt.
Also am Mozilla-FF kann es nicht liegen... doch, es liegt am FF. Und zwar an der Version 132, die lt. var/log/zypp/ history am 29.10. bei mir installiert wurde. Ich habe nun mein $HOME/.mozilla weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum ersetzt, welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024 installiert wurde. Dann habe ich noch die relevanten sqlite Dateien aus der Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles wieder wie gewohnt.
Am 30.10.24 um 10:37 schrieb Herbert Albert:
Am Mittwoch, 30. Oktober 2024, 07:33:38 CET schrieb Jörg Thümmler:
Am 29.10.24 um 19:55 schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:50:22 CET schrieb Herbert Albert:
Am Dienstag, 29. Oktober 2024, 19:25:31 CET schrieb Richard Kraut:
Am Dienstag, dem 29.10.2024 um 17:32 +0100 schrieb Herbert Albert:
/home/herbert/Downloads/Yl_ris5D.repo.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
Versuchen Sie es später erneut oder kontaktieren Sie den Server- Administrator.
Mit falkon geht es natürlich. Ich will jetzt aber nicht jedes Mal zu falkon wechseln. Es ging ja bis vor ein paar Tagen noch mit dem FF.
Wenn Dein $HOME, oder wo Dein Downloadordner auch immer liegt, nicht voll ist und sich auch bei den Berechtigungen nichts geändert hat, würde ich sagen, dass dies ein Bug ist.
auf $HOME ist noch Platz, an den Rechten hat sich nichts geändert und falkon und Vivaldi tun genau das, was FF bis vor kurzen auch getan hat. Entweder fragen, oder mit der Endung zugeordneter Applikation starten.
Was in FF geht ist, dass ich in den Einstellungen sage z. B. pdf mit der Systemstandardanwendung (okular) öffnen oder *.repo mit "Mit nedit öffnen". Kann man machen, aber dann fehlt mir die Wahlmöglichkeit mal was anderes zu machen.
Gruß
Herbert
habe noch ein bisschen rumprobiert. Scheint mit allen Dateiendungen zu sein, bei denen "Jedes Mal nachfragen" gewählt wurde. Und bei euch ist das nicht der Fall?
Hi,
ich lade immer die Updates von Mozilla selbst runter. Komischerweise hat er mich (noch?) nicht auf das 132er Update hingewiesen, aber ich habe den 132er jetzt installiert und PDF auf "jedes Mal fragen" gesetzt... macht er problemlos. Ich kann zwischen öffnen, öffnen mit Anwendung und Speichern wählen, und was ich wähle, wird auch ausgeführt.
Also am Mozilla-FF kann es nicht liegen... doch, es liegt am FF. Und zwar an der Version 132, die lt. var/log/zypp/ history am 29.10. bei mir installiert wurde. Ich habe nun mein $HOME/.mozilla weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum ersetzt, welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024 installiert wurde. Dann habe ich noch die relevanten sqlite Dateien aus der Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles wieder wie gewohnt.
Hi, dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein $HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell bearbeitet, das habe ich bislang immer nur auf das $HOME eines neuen Systems kopiert und weiter verwendet... ich nehme aber seit Jahren schon die Mozilla-Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den Fall der Fälle kopiert habe)... -- cu jth
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/log/zypp/ history am 29.10. bei mir installiert wurde. Ich habe nun mein $HOME/.mozilla weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum ersetzt, welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024 installiert wurde. Dann habe ich noch die relevanten sqlite Dateien aus der Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles wieder wie gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein $HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell bearbeitet, das habe ich bislang immer nur auf das $HOME eines neuen Systems kopiert und weiter verwendet... ich nehme aber seit Jahren schon die Mozilla- Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt: https://bugzilla.suse.com/show_bug.cgi?id=1232567
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/log/zypp/ history am 29.10. bei mir installiert wurde. Ich habe nun mein $HOME/.mozilla weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum ersetzt, welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024 installiert wurde. Dann habe ich noch die relevanten sqlite Dateien aus der Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles wieder wie gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein $HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell bearbeitet, das habe ich bislang immer nur auf das $HOME eines neuen Systems kopiert und weiter verwendet... ich nehme aber seit Jahren schon die Mozilla- Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt: https://bugzilla.suse.com/show_bug.cgi?id=1232567 Hallo Wolfgang,
danke. Ich habe die 131 jetzt erst einmal auf hold gesetzt. Denn wenn man einmal was mit der neueren Version geöffnet hat gibt es mit dem Profil kein zurück mehr. Es sei denn ich habe den Trick noch nicht verstanden. Gruß Herbert
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/log/zypp/ history am 29.10. bei mir installiert wurde. Ich habe nun mein $HOME/.mozilla weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum ersetzt, welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024 installiert wurde. Dann habe ich noch die relevanten sqlite Dateien aus der Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles wieder wie gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein $HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell bearbeitet, das habe ich bislang immer nur auf das $HOME eines neuen Systems kopiert und weiter verwendet... ich nehme aber seit Jahren schon die Mozilla- Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt: https://bugzilla.suse.com/show_bug.cgi?id=1232567 Hallo Wolfgang,
wie ich dem Bug Report entnehme sollten neue Pakete gebaut sein. Wenn ich hier http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/x86_64/[1] nachsehe, ist dort eine Version MozillaFirefox-132.0-lp155.5.1.x86_64.rpm vom 30.10.2024, 13:46. Ist das schon die korrigierte Version? Gruß Herbert -------- [1] http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/x86_64/
Am 31.10.24 um 13:37 schrieb Herbert Albert:
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/ log/zypp/
history am 29.10. bei mir installiert wurde. Ich habe nun mein
$HOME/.mozilla
weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum
ersetzt,
welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024
installiert wurde. Dann habe ich noch die relevanten sqlite Dateien
aus der
Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles
wieder wie
gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor
ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein
$HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell bearbeitet, das
habe ich bislang immer nur auf das $HOME eines neuen Systems kopiert und
weiter verwendet... ich nehme aber seit Jahren schon die Mozilla-
Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den
Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt:
Hallo Wolfgang,
wie ich dem Bug Report entnehme sollten neue Pakete gebaut sein. Wenn ich hier
http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/ x86_64/ <http://download.opensuse.org/repositories/mozilla/ openSUSE_Leap_15.5/x86_64/>
nachsehe, ist dort eine Version MozillaFirefox-132.0- lp155.5.1.x86_64.rpm vom
30.10.2024, 13:46. Ist das schon die korrigierte Version?
Es ist eine funktionierende Version ohne KDE Integration. Leider noch keine endgültig funktionierende Version mit KDE Integration. Wolfgang
Am Donnerstag, 31. Oktober 2024, 14:09:09 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 13:37 schrieb Herbert Albert:
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/
log/zypp/
history am 29.10. bei mir installiert wurde. Ich habe nun mein
$HOME/.mozilla
weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum
ersetzt,
welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024
installiert wurde. Dann habe ich noch die relevanten sqlite Dateien
aus der
Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles
wieder wie
gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor
ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein
$HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell
bearbeitet, das
habe ich bislang immer nur auf das $HOME eines neuen Systems
kopiert und
weiter verwendet... ich nehme aber seit Jahren schon die Mozilla-
Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den
Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt:
Hallo Wolfgang,
wie ich dem Bug Report entnehme sollten neue Pakete gebaut sein. Wenn ich hier
http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/ x86_64/ <http://download.opensuse.org/repositories/mozilla/ openSUSE_Leap_15.5/x86_64/>
nachsehe, ist dort eine Version MozillaFirefox-132.0- lp155.5.1.x86_64.rpm vom
30.10.2024, 13:46. Ist das schon die korrigierte Version?
Es ist eine funktionierende Version ohne KDE Integration. Leider noch keine endgültig funktionierende Version mit KDE Integration.
Wolfgang also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme ich mit, dass die finale Version bereit steht?
Am 31.10.24 um 14:13 schrieb Herbert Albert:
Am Donnerstag, 31. Oktober 2024, 14:09:09 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 13:37 schrieb Herbert Albert:
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
doch, es liegt am FF. Und zwar an der Version 132, die lt. var/
log/zypp/
history am 29.10. bei mir installiert wurde. Ich habe nun mein
$HOME/.mozilla
weg gesichert und durch eines aus dem Backup vor dem vor diesen Datum
ersetzt,
welches mit der Version 131 zusammenpasst, die bei mir am 17.10.2024
installiert wurde. Dann habe ich noch die relevanten sqlite Dateien
aus der
Sicherung in das Profilverzeichnis kopiert. Nun funktioniert alles
wieder wie
gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor
ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein
$HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell
bearbeitet, das
habe ich bislang immer nur auf das $HOME eines neuen Systems
kopiert und
weiter verwendet... ich nehme aber seit Jahren schon die Mozilla-
Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den
Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt:
Hallo Wolfgang,
wie ich dem Bug Report entnehme sollten neue Pakete gebaut sein. Wenn ich hier
http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/ x86_64/ <http://download.opensuse.org/repositories/mozilla/ openSUSE_Leap_15.5/x86_64/>
nachsehe, ist dort eine Version MozillaFirefox-132.0- lp155.5.1.x86_64.rpm vom
30.10.2024, 13:46. Ist das schon die korrigierte Version?
Es ist eine funktionierende Version ohne KDE Integration. Leider noch keine endgültig funktionierende Version mit KDE Integration.
Wolfgang also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme ich mit, dass die finale Version bereit steht?
Dann gibts wieder ein Update im Repo? Wolfgang
Am Donnerstag, 31. Oktober 2024, 15:34:09 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 14:13 schrieb Herbert Albert:
Am Donnerstag, 31. Oktober 2024, 14:09:09 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 13:37 schrieb Herbert Albert:
Am Mittwoch, 30. Oktober 2024, 11:11:50 CET schrieb Wolfgang Rosenauer:
Am 30.10.24 um 11:09 schrieb Jörg Thümmler:
> doch, es liegt am FF. Und zwar an der Version 132, die lt. var/
log/zypp/
> history am 29.10. bei mir installiert wurde. Ich habe nun mein > > $HOME/.mozilla > > weg gesichert und durch eines aus dem Backup vor dem vor diesen > Datum > > ersetzt, > > welches mit der Version 131 zusammenpasst, die bei mir am > 17.10.2024 > > installiert wurde. Dann habe ich noch die relevanten sqlite > Dateien > > aus der > > Sicherung in das Profilverzeichnis kopiert. Nun funktioniert > alles > > wieder wie > > gewohnt.
Hi,
dann ist es doch aber merkwürdig, dass die Version 132, die ich mir vor
ca. 3 Stunden direkt von Mozilla geholt habe, das nicht hat. Mein
$HOME/.mozilla habe ich seit ca. 10 Jahren nicht manuell
bearbeitet, das
habe ich bislang immer nur auf das $HOME eines neuen Systems
kopiert und
weiter verwendet... ich nehme aber seit Jahren schon die Mozilla-
Versionen von FF (64bit) und ersetz den alten (nachdem ich den für den
Fall der Fälle kopiert habe)...
wird jetzt hier verfolgt:
Hallo Wolfgang,
wie ich dem Bug Report entnehme sollten neue Pakete gebaut sein. Wenn ich hier
http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.5/ x86_64/ <http://download.opensuse.org/repositories/mozilla/ openSUSE_Leap_15.5/x86_64/>
nachsehe, ist dort eine Version MozillaFirefox-132.0- lp155.5.1.x86_64.rpm vom
30.10.2024, 13:46. Ist das schon die korrigierte Version?
Es ist eine funktionierende Version ohne KDE Integration. Leider noch keine endgültig funktionierende Version mit KDE Integration.
Wolfgang
also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme ich mit, dass die finale Version bereit steht?
Dann gibts wieder ein Update im Repo?
Wolfgang das wird ja jetzt schon angeboten zypper se -s MozillaFirefox
S | Name | Type | Version | Arch | Repository ---+------------------------------------+------------+---------------------------+-------- +-------------------------------------------- vl | MozillaFirefox | package | 132.0-lp155.5.1 | x86_64 | Mozilla based projects (openSUSE_Leap_15.5) il | MozillaFirefox | package | 131.0.3-lp155.2.1 | x86_64 | Mozilla based projects (openSUSE_Leap_15.5) doch woher weiß ich, welche dann die "endgültig funktionierende Version mit KDE Integration" ist? Zypper gibt mir kein Datum aus, wann das Paket gebaut wurde. D. h. ich muss jetzt schauen, wann es eine Version mit einer höheren Nummer als 5.1 gibt. Die Version, die bei mir nicht funktionierte hatte die 3.1.
Am 31.10.24 um 16:00 schrieb Herbert Albert:
also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme
ich
mit, dass die finale Version bereit steht?
Dann gibts wieder ein Update im Repo?
Wolfgang
das wird ja jetzt schon angeboten
zypper se -s MozillaFirefox
S | Name | Type | Version | Arch | Repository ---+------------------------------------+------------ +---------------------------+-------- +-------------------------------------------- vl | MozillaFirefox | package | 132.0-lp155.5.1 | x86_64 | Mozilla based projects (openSUSE_Leap_15.5) il | MozillaFirefox | package | 131.0.3-lp155.2.1 | x86_64 | Mozilla based projects (openSUSE_Leap_15.5)
doch woher weiß ich, welche dann die "endgültig funktionierende Version mit KDE Integration" ist? Zypper gibt mir kein Datum aus, wann das Paket gebaut wurde. D. h. ich muss jetzt schauen, wann es eine Version mit einer höheren Nummer als 5.1 gibt. Die Version, die bei mir nicht funktionierte hatte die 3.1.
ich werde hoffentlich keine Version mehr veröffentlich, bis das Problem nicht behoben ist. "Hoffentlich" deswegen, weil mir aktuell noch total unklar ist, woher das Problem kommt. Ich weiss welcher Patch aber ich nicht welche Stelle im Patch. :-( D.h., sobald zypper eine Version anbietet, sollte die komplett sein. Da muss man normalerweise keine Versionsnummern tracken. Wolfgang
Am Donnerstag, 31. Oktober 2024, 16:59:58 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 16:00 schrieb Herbert Albert:
also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme
ich
mit, dass die finale Version bereit steht?
Dann gibts wieder ein Update im Repo?
Wolfgang
das wird ja jetzt schon angeboten
zypper se -s MozillaFirefox
S | Name | Type | Version
| Arch | Repository
---+------------------------------------+------------ +---------------------------+-------- +-------------------------------------------- vl | MozillaFirefox | package | 132.0-lp155.5.1
| x86_64 | Mozilla based projects (openSUSE_Leap_15.5)
il | MozillaFirefox | package | 131.0.3-lp155.2.1
| x86_64 | Mozilla based projects (openSUSE_Leap_15.5)
doch woher weiß ich, welche dann die "endgültig funktionierende Version mit KDE Integration" ist? Zypper gibt mir kein Datum aus, wann das Paket gebaut wurde. D. h. ich muss jetzt schauen, wann es eine Version mit einer höheren Nummer als 5.1 gibt. Die Version, die bei mir nicht funktionierte hatte die 3.1.
ich werde hoffentlich keine Version mehr veröffentlich, bis das Problem nicht behoben ist. "Hoffentlich" deswegen, weil mir aktuell noch total unklar ist, woher das Problem kommt. Ich weiss welcher Patch aber ich nicht welche Stelle im Patch. :-( D.h., sobald zypper eine Version anbietet, sollte die komplett sein. Da muss man normalerweise keine Versionsnummern tracken.
Wolfgang Hallo Wolfgang,
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert. Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist? zypper ll # | Name | Type | Repository | Comment --+------------------------------------+---------+------------+-------- 1 | MozillaFirefox | package | (any) | 2 | MozillaFirefox-branding-upstream | package | (any) | 3 | MozillaFirefox-devel | package | (any) | 4 | MozillaFirefox-translations-common | package | (any) | Gruß Herbert
Am 31.10.24 um 18:21 schrieb Herbert Albert:
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert.
Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist?
Wenn Dir die Funktion 'KDE Integration' so wichtig ist, dass Du die von Wolfgang gebaute Interimslösung nicht nutzen möchtest, wirst Du aus meiner Sicht um eine manuelle Überprüfung nicht herumkommen, ja. Viele Grüße Ulf
Am 31.10.2024 um 20:00 schrieb Ulf Volmer:
Am 31.10.24 um 18:21 schrieb Herbert Albert:
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert.
Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist?
Wenn Dir die Funktion 'KDE Integration' so wichtig ist, dass Du die von Wolfgang gebaute Interimslösung nicht nutzen möchtest, wirst Du aus meiner Sicht um eine manuelle Überprüfung nicht herumkommen, ja.
Viele Grüße
Ulf
Boah! Er soll mal seine 131 Version weiter verwenden. Maaaaan, er tut ja grad so als wenn die Welt unterginge wenn er nicht das allerallerallerneuste auf seinem Rechner hat. So eine Krümelkackerei hab ich schon lange nicht mehr gesehen, sorry. Manfred
On Freitag, 1. November 2024 17:22:51 Mitteleuropäische Normalzeit Manfred Kreisl wrote:
Am 31.10.2024 um 20:00 schrieb Ulf Volmer:
Am 31.10.24 um 18:21 schrieb Herbert Albert:
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert.
Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist?
Wenn Dir die Funktion 'KDE Integration' so wichtig ist, dass Du die von Wolfgang gebaute Interimslösung nicht nutzen möchtest, wirst Du aus meiner Sicht um eine manuelle Überprüfung nicht herumkommen, ja.
Viele Grüße
Ulf
Boah! Er soll mal seine 131 Version weiter verwenden. Maaaaan, er tut ja grad so als wenn die Welt unterginge wenn er nicht das allerallerallerneuste auf seinem Rechner hat.
So eine Krümelkackerei hab ich schon lange nicht mehr gesehen, sorry.
Manfred
Boah! Ist das toll, wenn Jemand nix zum Thema oder gar der Lösung beiträgt, aber in unmöglichem Tonfall andere niedermacht. Maaaaan 8-(
Am 01.11.2024 um 17:33 schrieb mh@mike.franken.de:
On Freitag, 1. November 2024 17:22:51 Mitteleuropäische Normalzeit Manfred Kreisl wrote:
Am 31.10.2024 um 20:00 schrieb Ulf Volmer:
Am 31.10.24 um 18:21 schrieb Herbert Albert:
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert.
Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist?
Wenn Dir die Funktion 'KDE Integration' so wichtig ist, dass Du die von Wolfgang gebaute Interimslösung nicht nutzen möchtest, wirst Du aus meiner Sicht um eine manuelle Überprüfung nicht herumkommen, ja.
Viele Grüße
Ulf
Boah! Er soll mal seine 131 Version weiter verwenden. Maaaaan, er tut ja grad so als wenn die Welt unterginge wenn er nicht das allerallerallerneuste auf seinem Rechner hat.
So eine Krümelkackerei hab ich schon lange nicht mehr gesehen, sorry.
Manfred
Boah! Ist das toll, wenn Jemand nix zum Thema oder gar der Lösung beiträgt, aber in unmöglichem Tonfall andere niedermacht. Maaaaan 8-(
Lösung wurde genannt: Vorgängerversion verwenden. Selber schuld wenn man immer an vorderster Front der Updatewahnsinnigen stehen will
Am 01.11.24 um 18:07 schrieb Manfred Kreisl:
Lösung wurde genannt: Vorgängerversion verwenden. Selber schuld wenn man immer an vorderster Front der Updatewahnsinnigen stehen will
Warum grätscht Du denn hier rein, wenn Du den Thread entweder nicht verfolgt oder nicht verstanden hast? Fassungslos, Uld
On Freitag, 1. November 2024 18:13:10 Mitteleuropäische Normalzeit Ulf Volmer wrote:
Am 01.11.24 um 18:07 schrieb Manfred Kreisl:
Lösung wurde genannt: Vorgängerversion verwenden. Selber schuld wenn man immer an vorderster Front der Updatewahnsinnigen stehen will
Warum grätscht Du denn hier rein, wenn Du den Thread entweder nicht verfolgt oder nicht verstanden hast?
Fassungslos,
Uld
Weil er halt so ist - ist ja nicht das erste und einzige Mal 8-( Immer ein freundliches Wort für seine Mitmenschen vor allem.
Am Freitag, 1. November 2024, 17:22:51 CET schrieb Manfred Kreisl:
Am 31.10.2024 um 20:00 schrieb Ulf Volmer:
Am 31.10.24 um 18:21 schrieb Herbert Albert:
da habe ich jetzt noch ein Problem, wie ich das mit zypper oder Yast einrichten muss. Wie ich gestern geschrieben habe, habe ich die 131 per Yast auf geschützt gesetzt, damit mir die 132.3.1 nicht installiert wird. Nun gibt es im Repo die 132.5.1, von der Du sagst, dass es noch nicht die endgültige (KDE Integration) sei. Was müsste ich jetzt wie einstellen, dass mir durch die Updates das neue, noch nicht gebaute Paket angeboten wird. Wenn ich das richtig verstehe, wird mir solange ich die 131 auf geschützt stelle gar kein Firefox Paket durch z. B. zypper up angeboten. Nehme ich nun den Flag geschützt raus, wird mir doch das jetzt verfügbare Paket 132.5.1 installiert.
Habe ich da was nicht richtig verstanden oder muss ich da wirklich manuell nachsehen, wann ein Paket höher 132.5.1 vorhanden ist?
Wenn Dir die Funktion 'KDE Integration' so wichtig ist, dass Du die von Wolfgang gebaute Interimslösung nicht nutzen möchtest, wirst Du aus meiner Sicht um eine manuelle Überprüfung nicht herumkommen, ja.
Viele Grüße
Ulf
Boah! Er soll mal seine 131 Version weiter verwenden. Maaaaan, er tut ja grad so als wenn die Welt unterginge wenn er nicht das allerallerallerneuste auf seinem Rechner hat.
So eine Krümelkackerei hab ich schon lange nicht mehr gesehen, sorry.
Manfred was soll ich dazu sagen? Eigentlich nichts, wäre eh zwecklos.
Ich will nicht das Allerneueste auf meinen Rechner habe, darum habe ich auch noch noch nicht das Upgrade auf 15.6 gemacht, aber die angebotenen Updates, sind auch Sicherheitsupdates dabei, spiele ich schon ein und da ist der Fehler halt aufgetreten.
Am Donnerstag, 31. Oktober 2024, 16:59:58 CET schrieb Wolfgang Rosenauer:
Am 31.10.24 um 16:00 schrieb Herbert Albert:
also lieber noch warten? Die 131 funktioniert ja auch. Doch wie bekomme
ich
mit, dass die finale Version bereit steht?
Dann gibts wieder ein Update im Repo?
Wolfgang
das wird ja jetzt schon angeboten
zypper se -s MozillaFirefox
S | Name | Type | Version
| Arch | Repository
---+------------------------------------+------------ +---------------------------+-------- +-------------------------------------------- vl | MozillaFirefox | package | 132.0-lp155.5.1
| x86_64 | Mozilla based projects (openSUSE_Leap_15.5)
il | MozillaFirefox | package | 131.0.3-lp155.2.1
| x86_64 | Mozilla based projects (openSUSE_Leap_15.5)
doch woher weiß ich, welche dann die "endgültig funktionierende Version mit KDE Integration" ist? Zypper gibt mir kein Datum aus, wann das Paket gebaut wurde. D. h. ich muss jetzt schauen, wann es eine Version mit einer höheren Nummer als 5.1 gibt. Die Version, die bei mir nicht funktionierte hatte die 3.1.
ich werde hoffentlich keine Version mehr veröffentlich, bis das Problem nicht behoben ist. "Hoffentlich" deswegen, weil mir aktuell noch total unklar ist, woher das Problem kommt. Ich weiss welcher Patch aber ich nicht welche Stelle im Patch. :-( D.h., sobald zypper eine Version anbietet, sollte die komplett sein. Da muss man normalerweise keine Versionsnummern tracken.
Wolfgang Hallo Wolfgang,
die MozillaFirefox-132.0-lp155.8.1.x86_64 scheint wieder wie gewohnt zu funktionieren, auch wenn sich bei der Auswahl der zu startenden Applikation etwas geändert hat. Gruß Herbert
Hallo, Am 05.11.24 um 09:06 schrieb Herbert Albert:
Hallo Wolfgang,
die MozillaFirefox-132.0-lp155.8.1.x86_64 scheint wieder wie gewohnt zu funktionieren, auch wenn sich bei der Auswahl der zu startenden Applikation etwas geändert hat.
jo, Hintergrund, der auch im Bugzilla steht: Ich habe die Legacy KDE Patches entfernt, weil sie immer nur Ärger machen und ich noch nichtmal eine Spur gefunden habe, inwiefern sie das Fehlverhalten verursacht haben. Firefox hat seit einiger Zeit eine XDG Integration, die (hoffentlich) die meisten Usecases korrekt abdeckt. Das bedeutet, dass ich sehr an Feedback interessiert bin, ob irgendetwas nicht wie erwartet oder gewünscht funktioniert. Das bezieht sich auf alle Desktops also nicht nur KDE. Feedback von daher gerne in Bugzilla oder an mich direkt aber unbedingt mit der Information: 1. genaue Herkunft und Versionsnummer des MozillaFirefox Pakets 2. Herkunft und Versionsnummer des MozillaFirefox-branding-openSUSE Pakets 3. alternativ zu 2. die eingestellten Werte für widget.use-xdg-desktop-portal.file-picker widget.use-xdg-desktop-portal.mime-handler Und was passiert und was anstelle besser passieren hätte sollen. Danke, Wolfgang
Am Dienstag, 5. November 2024, 12:03:44 CET schrieb Wolfgang Rosenauer:
Hallo,
Am 05.11.24 um 09:06 schrieb Herbert Albert:
Hallo Wolfgang,
die MozillaFirefox-132.0-lp155.8.1.x86_64 scheint wieder wie gewohnt zu funktionieren, auch wenn sich bei der Auswahl der zu startenden Applikation etwas geändert hat.
jo, Hintergrund, der auch im Bugzilla steht: Ich habe die Legacy KDE Patches entfernt, weil sie immer nur Ärger machen und ich noch nichtmal eine Spur gefunden habe, inwiefern sie das Fehlverhalten verursacht haben. Firefox hat seit einiger Zeit eine XDG Integration, die (hoffentlich) die meisten Usecases korrekt abdeckt.
Das bedeutet, dass ich sehr an Feedback interessiert bin, ob irgendetwas nicht wie erwartet oder gewünscht funktioniert. Das bezieht sich auf alle Desktops also nicht nur KDE. Feedback von daher gerne in Bugzilla oder an mich direkt aber unbedingt mit der Information: 1. genaue Herkunft und Versionsnummer des MozillaFirefox Pakets 2. Herkunft und Versionsnummer des MozillaFirefox-branding-openSUSE Pakets 3. alternativ zu 2. die eingestellten Werte für widget.use-xdg-desktop-portal.file-picker widget.use-xdg-desktop-portal.mime-handler
Und was passiert und was anstelle besser passieren hätte sollen.
Danke, Wolfgang Hallo Wolfgang,
was genau machen denn die Legacy KDE Patches? Ist das so etwas wie der Dateimanager, der aufgeht, wenn ich z. B. im Download auf das Ordnersymbol klicke. Da geht ja nicht der KDE-Default-Dateimanager auf (bin mir jetzt gar nicht mehr sicher, ob das je anders war). Dann gibt es ja noch ein AdOn "Plasma Integration", das ist aber sicherlich etwas anderes. Im web finde ich dazu nichts erhellendes. Gruß Herbert
Am 05.11.24 um 17:32 schrieb Herbert Albert:
Hallo Wolfgang,
was genau machen denn die Legacy KDE Patches? Ist das so etwas wie der Dateimanager, der aufgeht, wenn ich z. B. im Download auf das Ordnersymbol klicke. Da geht ja nicht der KDE-Default-Dateimanager auf (bin mir jetzt gar nicht mehr sicher, ob das je anders war). Dann gibt es ja noch ein AdOn "Plasma Integration", das ist aber sicherlich etwas anderes. Im web finde ich dazu nichts erhellendes.
Die Patches im letzten Stand sorgten primär dafür, dass eben unter KDE Plasma der KDE Filepicker bzw. Application-Chooser aufging und man aus Firefox heraus z.B. das Hintergrundbild in KDE setzen konnte. Früher betraf das auch noch die Button-Order aber die müsste mittlerweile auch out-of-the-box gehen. Leider bin ich etwas überfragt, was davon am Ende noch problemlos funktioniert hat, weil ich schon 10 Jahre kein KDE mehr verwende. Aber zumindest war das die Erwartungshaltung. Wolfgang
Hallo Wolfgang, On 05.11.24 12:03, Wolfgang Rosenauer wrote:
Am 05.11.24 um 09:06 schrieb Herbert Albert:
die MozillaFirefox-132.0-lp155.8.1.x86_64 scheint wieder wie gewohnt zu funktionieren, auch wenn sich bei der Auswahl der zu startenden Applikation etwas geändert hat.
jo, Hintergrund, der auch im Bugzilla steht: Ich habe die Legacy KDE Patches entfernt, weil sie immer nur Ärger machen und ich noch nichtmal eine Spur gefunden habe, inwiefern sie das Fehlverhalten verursacht haben. Firefox hat seit einiger Zeit eine XDG Integration, die (hoffentlich) die meisten Usecases korrekt abdeckt.
Das bedeutet, dass ich sehr an Feedback interessiert bin, ob irgendetwas nicht wie erwartet oder gewünscht funktioniert. Das bezieht sich auf alle Desktops also nicht nur KDE. Feedback von daher gerne in Bugzilla oder an mich direkt aber unbedingt mit der Information: 1. genaue Herkunft und Versionsnummer des MozillaFirefox Pakets 2. Herkunft und Versionsnummer des MozillaFirefox-branding-openSUSE Pakets 3. alternativ zu 2. die eingestellten Werte für widget.use-xdg-desktop-portal.file-picker widget.use-xdg-desktop-portal.mime-handler
Und was passiert und was anstelle besser passieren hätte sollen.
Bei mir öffnet der File-Dialog gar nicht mehr - öffnen oder speichern von Dateien. Sowohl bei Firefox 132.0.1 als auch bei Thunderbird 128.4.3esr vom "Mozilla.Repo" auf openSUSE Leap 15.6. Ich benutze ein LXQT ohne empfohlene Pakete als WindowManager. Bisher gingen diese Dialoge ... Wenn ich "widget.use-xdg-desktop-portal.file-picker" von "1" (= default) auf "2" stelle öffnen sich die File-Dialoge wieder. Viele Grüße Holger -- SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Thu, 14 Nov 2024 23:25:46 +0100 Holger Sickenberg <holgi@opensuse.org> wrote: Guten Abend!
Bei mir öffnet der File-Dialog gar nicht mehr - öffnen oder speichern von Dateien. Das kann ich bestätigen. Allerdings sieht es so aus, als ob das nichts mit Firefox u.a., sondern mit dem Paket MozillaFirefox-branding-openSUSE zu tun hat.
Bis zu V. 68-lp155.18.1 funktionierte noch alles, danach trat der beschriebene Fehler auf. MozillaFirefox-branding-upstream ist von dem Fehler nicht betroffen. System: Leap 15.5, fvwm2 Aktuell aus dem Mozilla-Repository installiert: FF 132.0.1-lp155.3.1, MozillaFirefox-branding-openSUSE 68-lp155.18.1 Viele Grüße Matthias
Am 15.11.24 um 00:43 schrieb Matthias:
On Thu, 14 Nov 2024 23:25:46 +0100 Holger Sickenberg <holgi@opensuse.org> wrote:
Guten Abend!
Bei mir öffnet der File-Dialog gar nicht mehr - öffnen oder speichern von Dateien. Das kann ich bestätigen. Allerdings sieht es so aus, als ob das nichts mit Firefox u.a., sondern mit dem Paket MozillaFirefox-branding-openSUSE zu tun hat.
Bis zu V. 68-lp155.18.1 funktionierte noch alles, danach trat der beschriebene Fehler auf.
MozillaFirefox-branding-upstream ist von dem Fehler nicht betroffen.
System: Leap 15.5, fvwm2
Aktuell aus dem Mozilla-Repository installiert: FF 132.0.1-lp155.3.1, MozillaFirefox-branding-openSUSE 68-lp155.18.1
Viele Grüße
Matthias
Hi, das erklärt, warum der Original-FF von Mozilla die Probleme nicht kennt (übrigens kam gestern 132.0.2 raus...) ich verstehe nicht so ganz, was OS damit eigentlich noch treibt. Ich lasse automatisiert checken, ob es eine neue firefox...tar.bz2 gibt, wenn ja, läd das System die runter, verschiebt ein ff-Backup in ein anderes, den aktuellen ff in dieses Backup und entpackt den neuen - bei mir nach /usr/local. So kann ich im Zweifel immer 2 Versionen zurück (von denen ich ja weiß, das sie funktioniert haben). -- cu jth
Am 15.11.24 um 00:43 schrieb Matthias:
On Thu, 14 Nov 2024 23:25:46 +0100 Holger Sickenberg <holgi@opensuse.org> wrote:
Guten Abend!
Bei mir öffnet der File-Dialog gar nicht mehr - öffnen oder speichern von Dateien. Das kann ich bestätigen. Allerdings sieht es so aus, als ob das nichts mit Firefox u.a., sondern mit dem Paket MozillaFirefox-branding-openSUSE zu tun hat.
Bis zu V. 68-lp155.18.1 funktionierte noch alles, danach trat der beschriebene Fehler auf.
MozillaFirefox-branding-upstream ist von dem Fehler nicht betroffen.
System: Leap 15.5, fvwm2
Aktuell aus dem Mozilla-Repository installiert: FF 132.0.1-lp155.3.1, MozillaFirefox-branding-openSUSE 68-lp155.18.1
Der Workaround ist, widget.use-xdg-desktop-portal.file-picker auf 2 zu setzen. Tatsächlich setzt das letzte MozillaFirefox-branding-openSUSE Paket diesen Wert auf 1. Das führt offenbar aktuell zu zwei möglichen Fehlern: Kein Filedialog generell: Wahrscheinlich fehlt das Paket xdg-desktop-portal Kein Filedialog aus dem "Save as" Kontextmenü: https://bugzilla.suse.com/show_bug.cgi?id=1233377 Der Workaround oben behebt beide Probleme. Der erste Fall ist adressiert in einem neueren FF Paket, was noch zu submitten ist. Der zweite Fall ist noch unklar, siehe Bugzilla Wolfgang
Am Freitag, 15. November 2024, 10:08:56 CET schrieb Wolfgang Rosenauer:
Am 15.11.24 um 00:43 schrieb Matthias:
On Thu, 14 Nov 2024 23:25:46 +0100 Holger Sickenberg <holgi@opensuse.org> wrote:
Guten Abend!
Bei mir öffnet der File-Dialog gar nicht mehr - öffnen oder speichern von Dateien.
Das kann ich bestätigen. Allerdings sieht es so aus, als ob das nichts mit Firefox u.a., sondern mit dem Paket MozillaFirefox-branding-openSUSE zu tun hat.
Bis zu V. 68-lp155.18.1 funktionierte noch alles, danach trat der beschriebene Fehler auf.
MozillaFirefox-branding-upstream ist von dem Fehler nicht betroffen.
System: Leap 15.5, fvwm2
Aktuell aus dem Mozilla-Repository installiert: FF 132.0.1-lp155.3.1, MozillaFirefox-branding-openSUSE 68-lp155.18.1
Der Workaround ist, widget.use-xdg-desktop-portal.file-picker auf 2 zu setzen.
Tatsächlich setzt das letzte MozillaFirefox-branding-openSUSE Paket diesen Wert auf 1. Das führt offenbar aktuell zu zwei möglichen Fehlern:
Kein Filedialog generell: Wahrscheinlich fehlt das Paket xdg-desktop-portal
Kein Filedialog aus dem "Save as" Kontextmenü: https://bugzilla.suse.com/show_bug.cgi?id=1233377
Der Workaround oben behebt beide Probleme.
Der erste Fall ist adressiert in einem neueren FF Paket, was noch zu submitten ist. Der zweite Fall ist noch unklar, siehe Bugzilla
Wolfgang mittlerweile, nach mehreren Updates habe ich die MozillaFirefox-132.0.2-lp155.1.1.x86_64 und das Problem besteht wohl abhängig von Seiten, auf denen das PDF verlinkt ist bzw. zum Download angeboten wird.
Hier z. B. funktioniert es nicht https://www.viessmann.de/content/dam/public-brands/master/products/heat-pump... original.media_file.download_attachment.file/kpr-vitocal-250-a-vitocal-252-a.pdf[1] und hier z. B. schon https://www.linux-community.de/wp-content/uploads/2024/12/lu-ce_2024-12.pdf[2] Liegt das nun am FF oder an den Webseiten? -------- [1] https://www.viessmann.de/content/dam/public-brands/master/products/heat-pump... vitocal-250-a-neubau/kpr-vitocal-250-a-vitocal-252-a.pdf/_jcr_content/renditions/ original.media_file.download_attachment.file/kpr-vitocal-250-a-vitocal-252-a.pdf [2] https://www.linux-community.de/wp-content/uploads/2024/12/lu-ce_2024-12.pdf
Am 18.11.24 um 13:34 schrieb Herbert Albert:
mittlerweile, nach mehreren Updates habe ich die
MozillaFirefox-132.0.2-lp155.1.1.x86_64
und das Problem besteht wohl abhängig von Seiten, auf denen das PDF verlinkt ist bzw. zum Download angeboten wird.
Hier z. B. funktioniert es nicht
https://www.viessmann.de/content/dam/public-brands/master/products/heat- pump/vitocal-250-a-neubau/kpr-vitocal-250-a-vitocal-252-a.pdf/ _jcr_content/renditions/original.media_file.download_attachment.file/ kpr-vitocal-250-a-vitocal-252-a.pdf <https://www.viessmann.de/content/ dam/public-brands/master/products/heat-pump/vitocal-250-a-neubau/kpr- vitocal-250-a-vitocal-252-a.pdf/_jcr_content/renditions/ original.media_file.download_attachment.file/kpr-vitocal-250-a- vitocal-252-a.pdf>
und hier z. B. schon
https://www.linux-community.de/wp-content/uploads/2024/12/lu- ce_2024-12.pdf <https://www.linux-community.de/wp-content/ uploads/2024/12/lu-ce_2024-12.pdf>
Liegt das nun am FF oder an den Webseiten?
Es liegt an der Viessmann-Seite. Bei mir unter Librewolf kommt das Dialogfenster zum öffnen/speichern: Sie möchten folgende Datei öffnen kpr-vitocal-250-a-vitocal-252-a.pdf vom Typ ASC-Datei (3.3 MB) von www.viessmann.de zum öffnen läßt sich keine Anwendung anzeigen - nur andere .... Ich hab darüber Okular ausgewählt, so läßt sich die Datei anzeigen. Der Webprogrammierer hat scheinbar ein falsches Dateiformat als x-application der PDF-Datei mitgegegeben. -- Joachim Weber, Bonn Retired IT-Dinosaurier private Homepage: https://www.joachimweber.name Social-Networks.: Mastodon........: https://bonn.social/@trex Friendica.......: https://anonsys.net/profile/trex Pixelfed........: https://pixelfed.de/T-Rex https://www.kuketz-blog.de/das-fediverse-social-media-losgeloest-von-den-fes...
Am 18.11.24 um 14:23 schrieb Joachim Weber:
Am 18.11.24 um 13:34 schrieb Herbert Albert:
mittlerweile, nach mehreren Updates habe ich die
MozillaFirefox-132.0.2-lp155.1.1.x86_64
und das Problem besteht wohl abhängig von Seiten, auf denen das PDF verlinkt ist bzw. zum Download angeboten wird.
Hier z. B. funktioniert es nicht
https://www.viessmann.de/content/dam/public-brands/master/products/heat- pump/vitocal-250-a-neubau/kpr-vitocal-250-a-vitocal-252-a.pdf/ _jcr_content/renditions/original.media_file.download_attachment.file/ kpr-vitocal-250-a-vitocal-252-a.pdf <https://www.viessmann.de/content/ dam/public-brands/master/products/heat-pump/vitocal-250-a-neubau/kpr- vitocal-250-a-vitocal-252-a.pdf/_jcr_content/renditions/ original.media_file.download_attachment.file/kpr-vitocal-250-a- vitocal-252-a.pdf>
und hier z. B. schon
https://www.linux-community.de/wp-content/uploads/2024/12/lu- ce_2024-12.pdf <https://www.linux-community.de/wp-content/ uploads/2024/12/lu-ce_2024-12.pdf>
Liegt das nun am FF oder an den Webseiten?
Es liegt an der Viessmann-Seite. Bei mir unter Librewolf kommt das Dialogfenster zum öffnen/speichern:
Sie möchten folgende Datei öffnen
kpr-vitocal-250-a-vitocal-252-a.pdf
vom Typ ASC-Datei (3.3 MB) von www.viessmann.de
zum öffnen läßt sich keine Anwendung anzeigen - nur andere ....
Ich hab darüber Okular ausgewählt, so läßt sich die Datei anzeigen.
Der Webprogrammierer hat scheinbar ein falsches Dateiformat als x-application der PDF-Datei mitgegegeben. -- Joachim Weber, Bonn Retired IT-Dinosaurier
private Homepage: https://www.joachimweber.name Social-Networks.: Mastodon........: https://bonn.social/@trex Friendica.......: https://anonsys.net/profile/trex Pixelfed........: https://pixelfed.de/T-Rex
https://www.kuketz-blog.de/das-fediverse-social-media-losgeloest-von- den-fesseln-kommerzieller-interessen/
Hi, tatsächlich gibt es in meinem FF neuerdings 2 Arten PDF: Portable Document Format (PDF) (application/pdf) Portable Document Format (PDF) (application/x-download) die ich verschieden einstellen kann und tatsächlich ist der Standard bei x-download "Fragen" und FF wird mir nicht mal automatisch als Anwendung zum Öffnen vorgeschlagen, sondern nur bei mir installierte PDF-Programme (qpdf, mupdf, foxit.reader...) Offensichtlich nutzt die Viessmann-Seite letzteres [wenn Du schon ne Wärmepumpe suchst, dann doch nicht bei diesen Neu-Amis ;-)] was nichts daran ändert, dass die offizielle Mozilla-Version auch das korrekt handelt, nur eben das Suse-Branding nicht... -- cu jth
Am Montag, 18. November 2024, 15:13:38 CET schrieb Jörg Thümmler:
Am 18.11.24 um 14:23 schrieb Joachim Weber:
Am 18.11.24 um 13:34 schrieb Herbert Albert:
mittlerweile, nach mehreren Updates habe ich die
MozillaFirefox-132.0.2-lp155.1.1.x86_64
und das Problem besteht wohl abhängig von Seiten, auf denen das PDF verlinkt ist bzw. zum Download angeboten wird.
Hier z. B. funktioniert es nicht
https://www.viessmann.de/content/dam/public-brands/master/products/heat-> >> pump/vitocal-250-a-neubau/kpr-vitocal-250-a-vitocal-252-a.pdf/ _jcr_content/renditions/original.media_file.download_attachment.file/ kpr-vitocal-250-a-vitocal-252-a.pdf <https://www.viessmann.de/content/ dam/public-brands/master/products/heat-pump/vitocal-250-a-neubau/kpr- vitocal-250-a-vitocal-252-a.pdf/_jcr_content/renditions/ original.media_file.download_attachment.file/kpr-vitocal-250-a- vitocal-252-a.pdf>
und hier z. B. schon
https://www.linux-community.de/wp-content/uploads/2024/12/lu-> >> ce_2024-12.pdf <https://www.linux-community.de/wp-content/ uploads/2024/12/lu-ce_2024-12.pdf>
Liegt das nun am FF oder an den Webseiten?
Es liegt an der Viessmann-Seite. Bei mir unter Librewolf kommt das Dialogfenster zum öffnen/speichern:
Sie möchten folgende Datei öffnen
kpr-vitocal-250-a-vitocal-252-a.pdf
vom Typ ASC-Datei (3.3 MB) von www.viessmann.de
zum öffnen läßt sich keine Anwendung anzeigen - nur andere ....
Ich hab darüber Okular ausgewählt, so läßt sich die Datei anzeigen.
Der Webprogrammierer hat scheinbar ein falsches Dateiformat als x-application der PDF-Datei mitgegegeben.
Hi,
tatsächlich gibt es in meinem FF neuerdings 2 Arten PDF:
Portable Document Format (PDF) (application/pdf) Portable Document Format (PDF) (application/x-download)
die ich verschieden einstellen kann und tatsächlich ist der Standard bei x-download "Fragen" und FF wird mir nicht mal automatisch als Anwendung zum Öffnen vorgeschlagen, sondern nur bei mir installierte PDF-Programme (qpdf, mupdf, foxit.reader...)
Offensichtlich nutzt die Viessmann-Seite letzteres [wenn Du schon ne Wärmepumpe suchst, dann doch nicht bei diesen Neu-Amis ;-)]
was nichts daran ändert, dass die offizielle Mozilla-Version auch das korrekt handelt, nur eben das Suse-Branding nicht... den Typ gibt es in meinem FF nicht, jedoch habe ich gesehen das der besagte Link vom Typ application/x-download-Typ ist. Den habe ich nun auf jedes Mal nachfragen gestellt und nun geht es.
On Fri, 15 Nov 2024 10:08:56 +0100 Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote: Hallo Wolfgang! Sorry, daß ich mich erst jetzt wieder melden kann.
Der Workaround ist, widget.use-xdg-desktop-portal.file-picker auf 2 zu setzen. Danke, so funktioniert es; mittlerweile mit FF 132.0.2-lp155.1.1 und wieder MozillaFirefox-branding-openSUSE 68-lp155.21.1.
Viele Grüße Matthias
Am Dienstag, 29. Oktober 2024, 15:12:25 Mitteleuropäische Normalzeit schrieb Herbert Albert: [...]
problem mit Firefox beim laden einer PDF /home/herbert/Downloads/3QJP9Q- n.pdf.part
[...] War der einfach pingelig und dachte, mit der Endung "part", das lange ich gar nicht an? Normalerweise ist da der Download einfach noch nicht durch und die Datei nicht vollständig. Helga -- Technik - openSUSE Tumbleweed Politik - https://bge-community.de
Am Dienstag, 29. Oktober 2024, 18:38:00 CET schrieb Helga Fischer:
Am Dienstag, 29. Oktober 2024, 15:12:25 Mitteleuropäische Normalzeit schrieb Herbert Albert: [...]
problem mit Firefox beim laden einer PDF /home/herbert/Downloads/3QJP9Q- n.pdf.part
[...]
War der einfach pingelig und dachte, mit der Endung "part", das lange ich gar nicht an? Normalerweise ist da der Download einfach noch nicht durch und die Datei nicht vollständig.
Helga Hallo Helga,
da hilft aber auch kein warten. Es kommt ja gleich die Fehlermeldung. Gruß Herbert
Am 29.10.24 um 15:12 schrieb Herbert Albert: (...)
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen. Normal ist bei mir eingestellt, dass FF immer fragen soll, was mit der PDF geschehen soll (anzeigen mit okular oder speichern). Nun kommt die Meldung:
problem mit Firefox beim laden einer PDF /home/herbert/Downloads/3QJP9Q- n.pdf.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte. (...)
1. Gibt es dieses Datei überhaupt am angegebene Pfad? 2. Prüfen ob es ein "FF-Problem" ist -> Neues FF-Profil oder gleich anderer User. Bernd
Am Mittwoch, 30. Oktober 2024, 08:04:20 CET schrieb bnacht:
Am 29.10.24 um 15:12 schrieb Herbert Albert: (...)
mein Firefox 132.0 unter leap 15.5 weigert sich seit kurzem eine pdf Datei herunterzuladen. Normal ist bei mir eingestellt, dass FF immer fragen soll, was mit der PDF geschehen soll (anzeigen mit okular oder speichern). Nun kommt die Meldung:
problem mit Firefox beim laden einer PDF /home/herbert/Downloads/3QJP9Q- n.pdf.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.
(...)
1. Gibt es dieses Datei überhaupt am angegebene Pfad?
klar gibt es die Dateien. Wie beschrieben sind es ja nicht nur pdf, sonder alle Endungen, bei denen die Auswahl eingestellt ist.
2. Prüfen ob es ein "FF-Problem" ist -> Neues FF-Profil oder gleich anderer User.
Bernd
participants (14)
-
bnacht -
Helga Fischer -
Herbert Albert -
Holger Sickenberg -
Joachim Weber -
Jörg Thümmler -
Manfred Kreisl -
Matthias -
mh＠mike.franken.de -
Michael Behrens -
Richard Kraut -
Robert Großkopf -
Ulf Volmer -
Wolfgang Rosenauer