Beiträge von ArisCTR

CTR Schaltflächen
Der Grund für die Probleme mit einigen CTR Schaltflächen sind hohe dpi Werte in den Windows Einstellungen.
Mozilla bastelt fleißig die Symbole bzw. deren Dimensionen um und CTR und CTB sowie auch vollständige Themes müssen dieser Prozedur folgen, damit alle Schaltflächen wieder so aussehen wie sie sollen. Wer weiterhin die Standard-Einstellungen unter Windows nutzt, sollte vom Problem nicht betroffen sein.

Neue CTR und CTB Betas werden sich diesem Problem nach und nach annehmen.

Tab Probleme
Die meisten visuellen Fehler gehen zur Zeit auf das Konto von TabMixPlus. TMP ändert (nicht optional) diverse Bereiche der Tabs und Tableiste, die ab Fx39 Fehler verursachen. Zur Zeit wird an TMP auch nicht gearbeitet, so dass die Fehler mit den gerundeten Tabs mit und ohne CTR sichtbar sind. Wer TMP verwenden muss, sollte erst mal bei Fx38.x bleiben oder CTRs quadratische Tabs verwenden.

Doch, so verhalten sich die Standard-Schaltflächen unter Fx28 und Fx29-41. Deaktiviert die verschiebbaren Schaltflächen in den CTR Einstellungen und vergleicht sie mit den Standard-Schaltflächen..

Mir ist ein solcher Bug weder bekannt noch untergekommen.

Versuch mal im Modus Anpassen auf "Standard wiederherstellen" zu klicken.

Ansonsten einfach mal den Portable Firefox installieren und CTR dort testen um auszuschließen, dass der Grund eine Inkompatibilität mit CTR ist. Möglicherweise ist auch einfach nur das aktuelle Firefox Profil beschädigt.

Das Add-on "Hide Tabs Toolbar with one Tab" ist nicht kompatibel zu CTR und verursacht mit diversen Einstellungen Probleme. Es wird empfohlen die Funktion, die CTR bietet, zu verwenden.

Bei Fx 28 ohne Erweiterungen sieht man ein Popup sobald man auf Vor oder Zurück klickt den Mauszeiger nach unten bewegt. Selbiges gilt für Fx29+ bei den standard Vor/Zurück-Schaltflächen, also habe ich diese Funktion für CTRs "verschiebbare Vor/Zurück-Schaltflächen" ebenfalls integriert.

Das Popup erscheint aber nur bei gedrückte Maustauste. Bei einem normalen Klick kommt kein Popup.

Diese CTR Version bietet wieder die Option das Aktivieren des "Developer Themes" zu unterbinden (Fx40+).

https://www.dropbox.com/s/p0q5r63yomjv8z6/CTR_v1.3.3r3.xpi?dl=0

[Blockierte Grafik: http://i.imgur.com/fG72jh8.png]

Der Eintrag des "Developer Themes" wird im Add-ons Manager ausgeblendet, damit es nicht zu Komplikationen kommt, falls jemand auf die Idee kommt, das "Developer Theme" doch aktivieren zu wollen.

Nach einem Neustart kann die gewünschte Tabs-Form aktiviert werden. Weitere Neustarts sollten die Einstellungen nicht mehr zurücksetzen, so lange die Option aktiviert ist.

@ Sören
Keine Panik. War doch nur Spaß. Niemand unterstellt Mozilla böswilliges Verhalten.

Ich habe den Verdacht, dass dieser Weg Absicht ist.

Das Developer Theme ist jetzt ein Lightweight Theme (aka Persona) und wird im Add-ons Manager so wie andere Themes verwaltet.

Leider kann man es über die about:config Einstellung für lw-themes nicht einfach deaktivieren. Es sind zusätzliche Schalter nötig, auf die man nicht einfach so zugreifen kann (bzw. ich habe noch keinen Weg dazu gefunden). lightweightThemes.selectedThemeID zu ändern/löschen ist nicht ausreichend.

Die Developer Edition hat außerdem einen Bug, der (auch ohne Erweiterungen) das Developer Theme nach einem Neustart wieder aktiviert. Bei der Nightly Version tritt der Bug nicht auf.
Falls es keinen triftigen Grund gibt die Developer Edition zu verwenden und man das dunkle Developer Theme absolut nicht verwenden will, sollte man entweder zur Fx Beta oder Nightly wechseln.

Die Leseliste gibt es noch in der Nightly und in der Aurora Version von Firefox sowie in älteren 38.0 Betas und wer weiß ob die bei Mozilla nicht doch noch auf die Idee kommen diese Funktion in einer Fx 38.0.5+ Beta oder 39.x Beta wieder einzuführen.

Da ich innerhalb von CTR nicht zwischen Fx 38.0 und Fx 38.0.5 unterscheide, sehen Nutzer von Fx 38 bzw. 38.0.1 die Option Pocket zu (de)aktivieren, auch wenn Pocket nur ab 38.0.5 verfügbar ist.

Die Optionen in der Kategorie "Erweitert" können im Prinzip ignoriert werden, wenn man nicht weiß, was die machen. Es handelt sich ohnehin nur um Standardeinträge, die Firefox unter about:config führt, nicht CTR.

Danke. Immer diese Flüchtigkeitsfehler, die sich ungefragt einschleichen. :wink:

Ich wollte hier mal eine kleine Info hinterlassen bzgl. der Freigabedauer von Add-ons.

Es werden nur grobe Richtwerte veröffentlicht wie lange ein Add-on durchschnittlich in der Warteschlange ist, bevor es überprüft wird, abhängig von der Warteschlange auf der es sich befindet (Vollständige Überprüfungen, Vorläufige Überprüfungen oder Updates).
Es gibt keine Garantie dafür, dass ein Add-on tatsächlich nach einer bestimmten Zeit überprüft wird.

"Prüfer" wählen Add-ons aus freien Stücken auch unabhängig von der Warteschlange aus, d.h. eine Erweiterung kann auf dem letzten Platz in der Warteschlange stehen und trotzdem direkt nach dem Hochladen geprüft/freigegeben werden, es kann aber auch Monate dauern bis das passiert.
Hier mal eine aktueller Screenshot der aktuell am längsten 'wartenden' Add-ons aus der "Liste" (ohne Namen natürlich :mrgreen: http://i.imgur.com/naMXlAM.png

clamdrib LIN 0.2.1.3 ist laut System seit drei Tagen in der Warteschlange, d.h. es kann noch einige Zeit vergehen.
Dazu ist es eine Erweiterung nur für Seamonkey und Thunderbird unter Linux. Das schränkt den möglichen Prüferkreis natürlich etwas ein. Da eine "Vollständige Überprüfung" gewünscht wurde, ist der Aufwand größer als bei einer "Vorläufigen Überprüfung" und kann deswegen einiges an Zeit benötigen.

Bei mir funktioniert Multirow Bookmarks Toolbar Plus 1.5 mit und ohne CTR gleich gut/schlecht. Lesezeichen lassen sich in beiden Fällen nicht in Ordner verschieben.

Wüsste auch nicht in wie weit CTR in die Multirow Bookmarks Toolbar Plus 1.5 Erweiterung eingreifen sollte. Code dafür gibt es keinen.

EDIT

Ich habe gerade mal in den "AMO Editor" Bereich geschaut. Die Version 1.2 hatte einige Fehler, die weder in den Versionen 1.3 noch 1.4 behoben wurden. Deswegen wurden diese Versionen von den AMO Servern entfernt.

OK, die aktuelle Beta ist jetzt frei von dieser Funktion/Überprüfung. Es waren dann doch zu viele Mails mit "Beschwerden".

Eingebaut habe ich sie damit Nutzer die Adressleiste nicht fälschlicherweise im Anpassen-Modus von den Leisten entfernen (was dank CTR möglich ist). Falls die Leiste irgendwo zwischen den anderen Elementen im Anpassen-Modus oder im Aufklappmenü platziert wird, funktioniert der Anpassen-Modus nach einem Neustart nicht mehr.

@pittifox
Die Einstellung muss deaktiviert werden, damit die Überprüfung nicht mehr stattfindet und diese Meldung nicht mehr vorkommt. Das o.g. Problem kannst du dann aber nicht mehr lösen ohne CTR zu deaktivieren und wieder zu reaktivieren.

Das ist bei Add-ons, die die xpi Datei nicht entpacken unnötig, da die alte Datei durch die neue ersetzt wird. Das einzige was übrig bleiben könnte, sind nicht mehr verwendete Einstellungseinträge in der lokalen "prefs.js", die aber auch keinen Schaden anrichten können, weil sie eben nicht mehr verwendet werden.

Falls man natürlich nicht weiß welches Add-on das xpi Archiv entpackt, macht das Deinstallieren durchaus Sinn. Bei CTR, CTB oder anderen Erweiterungen von mir ist das aber nicht nötig.

Ich konnte keine Problem mit der 31ESR feststellen.
Es ist aber auch möglich, dass dein Firefoxprofil irgendwie Probleme macht pitttifox. Wenn du Zeit hast, kannst du mit einem neuen Profil testen. Übrigens ist Portable Firefox perfekt für so etwas und man muss auch nicht bei der ESR (aus welchen Gründen auch immer) bleiben.

Um das Problem in solchen Fällen generell zu lösen, habe ich eine neue Option in die Adressleistenkategorie eingefügt, die diese Überprüfung unterbindet.

https://www.dropbox.com/s/f0k16fm6v499ann/CTR_v1.3.0r15.xpi?dl=0

Evtl. werde ich die Überprüfung der Adressleistenposition ganz über Bord werfen, da sie aus unerklärlichen Gründen auf einigen Systemen nicht richtig funktionieren will.

Wundert mich auch, dass die Überprüfung bei dir zu diesem Ergebnis führt. Ich werde noch ein wenig an dieser Funktion "basteln" und falls in Zukunft etwas wieder nicht funktionieren wird, einfach hier reinschreiben oder mir eine Email schicken.

Die Funktion in CTR funktioniert so:

if(CustomizableUI.getPlacementOfWidget("urlbar-container")==null
  || CustomizableUI.getPlacementOfWidget("urlbar-container").area == "PanelUI-contents") {
 CustomizableUI.addWidgetToArea("urlbar-container", CustomizableUI.AREA_NAVBAR);
}

CustomizableUI.getPlacementOfWidget("urlbar-container")==null
>>> falls die Position vom Element "urlbar-container" auf keiner Leiste gefunden werden kann

oder

CustomizableUI.getPlacementOfWidget("urlbar-container").area == "PanelUI-contents"
>>> wenn das Element im Haupt-Aufklappmenü von Firefox ist

CustomizableUI.addWidgetToArea("urlbar-container", CustomizableUI.AREA_NAVBAR);
>>> verschiebe das Element zurück auf die Navigationsleiste

Ich habe den Test zeitlich etwas verzögert. Evtl. hilft das deinem alten Profile Edvoldi:

https://www.dropbox.com/s/o2yoph0jln7rhfx/CTR_v1.3.0r10.xpi?dl=0

OK, testet mal diese Version:

https://www.dropbox.com/s/cru813p6syn2wc9/CTR_v1.3.0r9.xpi?dl=0

Wo ist bzw. war die Adressleiste bisher? Auf einer der Leisten oder zwischen den anderen nicht platzierten Elementen im Anpassen-Modus?

Da der Anpassen-Modus nicht mehr zugänglich ist sobald die Adressleiste nicht auffindbar ist, "setzt CTR die Position der Adressleiste zurück", zeigt o.g. Meldung und schiebt die Adressleiste auf die Navigationsleiste, aber nur wenn sie "nicht gefunden" werden kann.
Sie wird als "nicht gefunden" eingestuft, falls sie irgendwo im Anpassen-Modus zwischen den anderen Elementen unter "Weitere Werkzeuge und Funktionen" oder im "Hauptmenü" platziert wird.

Ist das nicht der Fall?

Zitat von TmoWizard

Hallöchen @Sören!

Mir fällt hierbei nochmal eine Frage ein:

Wie soll das eigentlich mit Add-ons funktionieren, die für SeaMonkey und Firefox/Thunderbird existieren? Das ist ja ein und dieselbe *.xpi, siehe z. B. Adblock Plus!

Falls die xpi für mehrere Produkte (inkl. Firefox) angeboten wird, muss sie vor der Freigabe natürlich signiert werden bevor sie als Update/Download für alle Produkte zur Verfügung steht. Natürlich könnte man tricksen und ein und dieselbe Version für Firefox und für Thunderbird/Seamonkey anbieten aber verschiedene xpis hochladen.

[Blockierte Grafik: http://i.imgur.com/b277RFs.png]

Entwickler und Übersetzer, die ihre Änderungen lokal auf aktuellen Firefox Versionen testen wollen, werden keine wirklichen Probleme durch das neue Verfahren bekommen wie dem offiziellen Beitrag auf Mozilla und Sörens Artikel zu entnehmen ist.

Zitat

Installation of unsigned extensions will still be possible on Nightly and Developer Edition, as well as special, unbranded builds of Release and Beta that will be available mainly for developers testing their extensions.

https://blog.mozilla.org/addons/2015/02…fer-experience/

Zitat

In der Nightly Version sowie in der Firefox Developer Edition wird man auch nicht signierte Add-ons installieren können. Darüber hinaus wird es spezielle Release- und Beta-Builds ohne Firefox-Branding geben, welche zu Testzwecken genutzt werden können. Diese erlauben auch die Installation nicht signierter Add-ons.

https://www.soeren-hentzschel.at/mozilla/firefo…ng-von-add-ons/