Webseiten mit 404 Fehler finden

Eine vierte Versionsstelle hat normalerweise nicht die Bedeutung „Beta“. Ob es einzelne Entwickler gibt, die ihre Beta-Versionen so versionieren, weiß ich allerdings nicht. Gehört habe ich sowas noch nicht.

Eine vierte Versionsstelle macht jedenfalls keine realen Probleme (und ist auch erlaubt), genauso wenig wie mein „b1“-Zusatz am Ende echte Probleme macht. Der Punkt ist ganz einfach der, dass AMO Erweiterungen mit einer solchen Versionsnummer ablehnen würde. Deswegen beklagt sich Firefox seit Version 108, wenn die Versionsnummer ein „fehlerhaftes“ Format hat. Für eine Version, die ohnehin so nicht verteilt wird, ist das egal. Mozilla hat die für AMO erlaubten Möglichkeiten nur irgendwann limitiert, um einerseits die ganze Technik dahinter für Versionsvergleiche und Erweiterungs-Updates zu vereinfachen, und andererseits zwecks Kompatibilität damit, was Google für Chrome erlaubt.

Beispiel: Ublock 1.51.0, alles tutti. ublock 1.51.0.1 weisst sich als Beta aus in der Liste, und ist nicht 100% mehr kompatibel, auch wenn sich am Code selbst nichts verändert hat.

Und die Meldung bei Andreas beinhaltet nicht "should", sondern "must", und das ist im Englischen eindeutig. Aus Laiensicht sollte das heissen, dass man es mit was anderes als Zahlen in der Versionsangabe nicht mehr signiert bekommt. Dein XPI ist dahingehend ja auch nicht signiert, aber das dürfte andere Ursachen haben

Zitat von .DeJaVu

Beispiel: Ublock 1.51.0, alles tutti. ublock 1.51.0.1 weisst sich als Beta aus in der Liste, und ist nicht 100% mehr kompatibel, auch wenn sich am Code selbst nichts verändert hat.

Wenn die vierte Versionsstelle „Beta“ bedeuten soll, ist das aber eine ganz spezielle Eigenheit von Gorhill, die semantisch überhaupt keinen Sinn ergibt. Denn eine Version 1.51.0 Beta 1 wäre kleiner als eine Version 1.51.0, während eine Version 1.51.0.1 aber größer als eine Version 1.51.0 ist. Und da er die Beta-Versionen ohnehin nicht über AMO oder den Chrome Web Store verteilt, müsste er die vierte Stelle der Versionsnummer dafür auch gar nicht zweckentfremden. Aber wenn es seinen Release-Prozess aus irgendwelchen Gründen vereinfacht, soll er es so machen. Updates von Beta- auf finale Versionen gibt es bei ihm ja nicht. Das wäre auf diese Weise aus dem genannten Grund nämlich nicht möglich, ohne die Versionsnummer der finalen Versionen gegenüber den Beta-Versionen zu erhöhen. Gibt es aber nicht, also kein Problem.

Zitat von .DeJaVu

Und die Meldung bei Andreas beinhaltet nicht "should", sondern "must", und das ist im Englischen eindeutig. Aus Laiensicht sollte das heissen, dass man es mit was anderes als Zahlen in der Versionsangabe nicht mehr signiert bekommt. Dein XPI ist dahingehend ja auch nicht signiert, aber das dürfte andere Ursachen haben

Ja, man muss nach Standard. Aber wie gesagt, für Firefox selbst ist das völlig egal. Dadurch entstehen keine Probleme, Firefox verweigert nichts, wenn man sich daran nicht hält. Test-Versionen kann man versionieren, wie man lustig ist. Relevant werden die Anforderungen erst, wenn es um die Distribution via AMO oder den Chrome Web Store geht, denn dort ist dann kein Upload der Erweiterung möglich. Und deswegen wurde die Warnung (ausdrücklich kein Fehler!) in Firefox 108 ergänzt. Ich habe noch nicht die finale Versionsnummer verwendet, weil ich nicht wollte, dass die Version so in den Statistiken auftaucht, solange es nicht tatsächlich die finale Version ist.

Meine gestern hier hochgeladene Version ist davon unabhängig nicht signiert, da es für einen schnellen Test via about:debugging durch ein paar Nutzer nicht notwendig ist und es diese Version offiziell ja gar nicht gibt. Die Version wird heute noch aufgeräumt (da befindet sich noch ungenutzter Code aus meinem Entwicklungszweig drin, der damit nichts zu tun hat) und mit „sauberer“ Versionsnummer auf AMO hochgeladen, womit sie dann auch signiert sein wird.

Im Gegensatz zur Final läuft die bookmarks_organizer-4.1.1b1 wunderbar,

gerade über 600 Lesezeichen überprüft und ausgemistet.

Danke.

Ich habe das gerade mal im aktuellen Nightly versucht.

Via about:debugging die o.a. Erweiterung aufgerufen...

Ergebnis: Oberfläche wird angezeigt und die 3 Punkte rödeln... und wird nicht fertig. Übrigens auch mit der Version 3.1.0!

Neustart Firefox mit Cache-Leerung, alte Version 3.1.0 gelöscht,

Neustart Firefox.. about:debugging, o.a. Erweiterung geladen und gestartet... gleiches Ergebnis!

Wie lange muss man suchen lassen bei geschätzt 1000 Lesezeichen?

Kann dies jemand bestätigen oder mache ich grundsätzlich etwas falsch?

Beim anschließenden Neustart stürzt Nightly ab

Nachtrag: Nach wiederholtem Neustart noch einmal die Beta-Variante getestet. Jetzt werden die 1054 Lesezeichen erkannt, aber wie starte ich jetzt den Durchlauf?

Was zeigt der Fortschritt oben denn an?

Für deine Zahl ca 2,5 Minuten, für meine 1632 sind gewesen ca 3:15, Rechner ist auch auf Volllast in der Zeit.

Zitat von Boersenfeger

Kann dies jemand bestätigen

Ich zumindest nicht.

Aktuelle Nightly Version mit rund 700 Lesezeichen.

Dauer rund 40 Sekunden bis zu dieser Ansicht:

Zitat von Boersenfeger

wie starte ich jetzt den Durchlauf?

Auf den rechten Button klicken.

Mira_Belle: Danke!

Boersenfeger. Auch dir Danke für's Testen. Der Test mit der Version 3.1.0 ist nicht so zielführend, weil erstens noch eine andere Architektur (MV2 vs. MV3, das hat unter der Haube einiges geändert) und zweitens, weil es in späteren Versionen ein paar wichtige Bugfixes gab. Wenn beispielsweise ein Lesezeichen hinzugefügt wurde, während der Bookmarks Organizer bereits aktiv war, hätte das in Version 3.1.0 in jedem Fall dazu geführt, dass die Prüfung nicht erfolgreich durchläuft. Daher lass uns nur über Version 4.1.1 Beta 1 sprechen.

Da die Version 4.1.1 Beta hier und auf GitHub bislang bei allen, die getestet haben, erfolgreich durchlief, könnte es in deinem Fall ein anderes Problem sein und vielleicht mit einem bestimmten Lesezeichen zusammenhängen. Oder falls Ordner und/oder Trennlinien verwendet werden, liegt vielleicht dort irgendwo die Ursache. Ich befürchte leider, dass ich eine exakte Sicherung der Lesezeichen bräuchte, um das reproduzieren zu können.

Was die benötigte Zeit betrifft: Schwierig zu sagen. Die Antwortzeit der jeweiligen Server kann unterschiedlich sein. Je nachdem, ob vom Server die erste HEAD-Anfrage abgelehnt wird oder nicht, folgte eine zweite GET-Anfrage oder nicht. Bei vielen Anfragen innerhalb kurzer Zeit an die gleiche Domain könnte der Server dich drosseln. Deine Internet-Geschwindigkeit beeinflusst die Dauer jeder Anfrage. Und je nachdem, wie stabil oder nicht stabil deine Internetverbindung ist, könnten die bis zu 10 gleichzeitigen Anfragen des Bookmarks Organizers das Internet verlangsamen, entweder von Anfang an oder erst nach einer gewissen Anzahl durchgeführter Anfragen. Es entspricht auch meiner eigenen Erfahrung, dass bei einer Überprüfung von ein paar tausend Lesezeichen der Fortschritt meistens anfangs sehr viel schneller ist als zu einem späteren Zeitpunkt. Wird WLAN genutzt, ist das Signal vielleicht nicht immer gleich gut. Eventuell musst du gerade Bandbreite mit anderen Anwendungen teilen. Die Auslastung des Internetanbieters oder das Wetter können ebenso die Internetleistung beeinflussen. Lange Rede, kurzer Sinn: Da spielen so viele Faktoren mit rein, dass eine Schätzung schwierig ist. Und die Werte des einen können für den nächsten ganz anders aussehen.

Ich kann dir nur einen Maximalwert geben: Der Bookmarks Organizer führt maximal zwei Anfragen pro Lesezeichen durch und wartet maximal 15 Sekunden pro Anfrage auf eine Antwort. Bei 1.000 Lesezeichen sind das maximal 30.000 Sekunden, also acht Stunden. Vorausgesetzt, der Bookmarks Organizer bleibt nicht aus irgendeinem Grund dauerhaft stecken, dann gibt es kein Ende. Den Fall soll es natürlich eigentlich nicht geben. In der Regel ist man bei der Anzahl aber deutlich schneller. Eher im Bereich ein paar Minuten als ein paar Stunden.

Danke, ich teste morgen nochmal, muss jetzt weg..

der rechte Button ist nicht aktiv, ist auf dem o.a. Screenshot sichtbar...

Zitat von Boersenfeger

Beim anschließenden Neustart stürzt Nightly ab

Daran dürfte der Bookmarks Organizer unschuldig sein. Die Erweiterung wird bei den installierten Erweiterungen nicht aufgelistet und der Absturz scheint bei einem Export der Lesezeichen passiert zu sein.

Zitat von Boersenfeger

der rechte Button ist nicht aktiv, ist auf dem o.a. Screenshot sichtbar...

Wie sieht es nach einem Neuladen der Oberfläche vom Bookmarks Organizer aus? Deaktiviert sollte der Button eigentlich nur bei fehlender Berechtigung sowie während einer aktiven Überprüfung sein oder wenn es keine Lesezeichen gibt. Jede andere Situation mit diesem Ergebnis wäre ein Bug in der Erweiterung, wo man dann herausfinden müsste, was die Ursache ist.

Ich habe ebenfalls getestet, vorhin im Nightly. Kein Problem, allerdings habe ich lediglich 556 Lesezeichen, weil ich mich hauptsächlich auf bestimmten Standardwebseiten herumtreibe. Dadurch ging es ziemlich schnell.

So, heute Nightly-UpDate gemacht, via about : debugging die Erweiterung geladen.

Die 1054 Lesezeichen werden gefunden aber der Button 'Lesezeichen prüfen' bleibt unanklickbar.

Wenn ich die Seite via F5 neulade ,rödelt die Suche und wird nicht beendet, wenn ich die Erweiterung/das Script in about:debugging beende und neu lade, rödelt die Suche auch und wird nicht beendet...

Zitat von Boersenfeger

So, heute Nightly-UpDate gemacht, via about : debugging die Erweiterung geladen.

Du arbeitest doch mit dem Nightly. Da brauchst du kein about:debugging. Das brauchst du nur bei Verwendung der finalen Version. Beim Nightly kannst du in about:config die Einstellung xpinstall.signatures.required auf false setzen. Im Nightly wirkt das noch, in der finalen Version schon lange nicht mehr.

Zitat von Boersenfeger

Die 1054 Lesezeichen werden gefunden aber der Button 'Lesezeichen prüfen' bleibt unanklickbar.

Sehr interessant. Da muss tatsächlich was mit deinen Lesezeichen sein, was die Erweiterung durcheinanderbringt. Wäre das Teilen deiner Leseszeichen mit mir möglich oder eher nicht wegen Privatsphäre-Bedenken?

Zitat von milupo

Du arbeitest doch mit dem Nightly. Da brauchst du kein about:debugging.

about:debugging hat die Vorteile, dass man die Signaturpflicht nicht deaktivieren muss und die Erweiterung automatisch wieder entfernt wird, wenn man Firefox neu startet - was ich in dem Fall als Vorteil erachte, weil ich ja gar nicht möchte, dass jemand dauerhaft diese Version nutzt.

---

Die finale Version wurde gestern bei Mozilla eingereicht und sollte bald zur Verfügung stehen.

milupo Die Einstellung ist natürlich seit Jahren eingeschaltet. Aber auch, wenn ich die Erweiterung neu in Nightly installiere, funktioniert es nicht.

Sören Hentzschel Meine Lesezeichen möchte ich nicht teilen.

Ich hatte gestern mal eine Absturz ID verlinkt. Ggf. kann man da was erkennen.

Auch heute ist Nightly beim Neustart wieder abgestürzt. Hier wird zusätzlich das Hochladen via Absturzmanager nicht fertig und eine ID wird entsprechend nicht erstellt.

Steht eigentlich sehr unmissverständlich dran, was Phase ist:

Zitat

AsyncShutdownTimeout | profile-change-teardown | Places: export bookmarks.html ]

Zitat

AbortMessage ###!!! ABORT: file resource:///modules/BrowserGlue.sys.mjs:3395

Zitat

if (autoExportHTML) {

// Sqlite.sys.mjs and Places shutdown happen at profile-before-change, thus,

// to be on the safe side, this should run earlier.

lazy.AsyncShutdown.profileChangeTeardown.addBlocker( <---

"Places: export bookmarks.html",

() =>

lazy.BookmarkHTMLUtils.exportToFile(

lazy.BookmarkHTMLUtils.defaultPath

)

);

Alles anzeigen

Zitat von Boersenfeger

Sören Hentzschel Meine Lesezeichen möchte ich nicht teilen.

Das verstehe ich. Allerdings habe ich das Problem, dass ich von niemandem sonst von diesem Problem gehört habe und ich keine Idee habe, was die Ursache sein könnte, wenn ich das nicht irgendwie untersuchen kann. Mir würde sonst nur einfallen, dass du in einem Testprofil Lesezeichen schrittweise reduzierst, um so das Problem einzugrenzen. Das wäre dann aber halt für dich entsprechend viel Arbeit.

Zitat von Boersenfeger

Ich hatte gestern mal eine Absturz ID verlinkt. Ggf. kann man da was erkennen.

Siehe Beitrag #410. Das sieht für mich nicht danach aus, als hätte das mit dem Bookmarks Organizer zu tun. Und vor allem würde ein Absturz nicht erklären, wieso der Button nicht aktiv ist.

Zitat von Sören Hentzschel

Versionsnummer 4.1.1b1

Ist das ein grafischer Fehler oder ist das so geplant? Der Fortschrittsbalken sollte bei Punkt 2 beginnen, aber er beginnt unsichtbar bei Punkt 1. Die wechselnden Zahlen und die falsche Abwesenheit des Fortschrittsbalkens sind für den Benutzer etwas verwirrend.

Es stimmt, der Fortschrittsbalken könnte etwas weiter rechts beginnen. Aber etwas weiter links als die von dir gesetzte Pfeilspitze, damit durch die Schräge keine leere Ecke entsteht. Abgesehen davon, dass es für Nutzer mit mehr Lesezeichen einen kleinen Moment länger dauert, bis der Fortschrittsbalken sichtbar wird, hat das aber keine negativen Auswirkungen. Ich werde das daher mit dem nächsten geplanten Update verbessern, aber nicht deswegen ein weiteres kurzfristiges Update hinterschieben, jetzt wo sich Version 4.1.1 bereits im Veröffentlichungsprozess befindet. Danke für's Melden!

Ich habe ein entsprechendes GitHub Issue erstellt:

wrong start position for progress bar · Issue #231 · cadeyrn/bookmarks-organizer

The progress bar has a wrong start position. Users with many bookmarks may see the progress bar only after a little time has passed.

github.com

Zitat von Sören Hentzschel

Das verstehe ich. Allerdings habe ich das Problem, dass ich von niemandem sonst von diesem Problem gehört habe und ich keine Idee habe, was die Ursache sein könnte, wenn ich das nicht irgendwie untersuchen kann. Mir würde sonst nur einfallen, dass du in einem Testprofil Lesezeichen schrittweise reduzierst, um so das Problem einzugrenzen.

Ich warte jetzt mal auf die neue Version, teste und melde mich wieder. Die andere Lesezeichenerweiterung Keep or Delete funktioniert hier übrigens ebenfalls nicht im Nightly. Und beide auch nicht im Release Firefox 117.0