Beiträge von Speravir

Zitat von ArisCTR

Speravir
Ich habe den Code in mehreren Scripten gleichzeitig und es funktioniert.
Siehe hier z.B. https://github.com/Aris-t2/Custom…onbar.uc.js#L19

Ich weiß, das habe ich verklausuliert mit

Zitat

und bemerkte, dass dort weitere Änderungen besprochen und von Aris auch durchgeführt wurden.

gemeint.

Ach, du Sch*, erzeugt dieses Skript addonbar.uc.js etwa ebenso eine untere Statusleiste? Beim genaueren Hinsehen finde ich den Hinweis auf die ID browser-bottombox (aber auch einen Timeout, den ich ja entfernt hatte) … Browserwerkzeuge gestartet … Tatsächlich, eine Vbox mit dieser ID findet sich unterhalb des Hauptinhalts. Muss ich das also mal runterladen und einen Neustart machen.

Edit: Ja, funktioniert prima!

Ich bin anscheinend zu begriffstutzig, denn bei mir funktioniert das nicht.

Zitat von aborix

Damit bei zusätzlichen Symbolleisten der Inhalt neuer Fenster angezeigt wird, hatten wir zuletzt den Code aus #2186.

Ich hatte diesen Code in eine eigene Datei gelegt.

Zitat von aborix

Diesen Workaround brauchen wir nicht mehr, wir können nun die Ursache mit einer Code-Zeile beheben:

Code

gBrowser.selectedBrowser.removeAttribute('blank');

Die Zeile kann in ein eigenes Skript gegeben werden

Ich habe also im eigenen Skript alles entfernt und nur die Zeile eingefügt. Addon- und Privatmodusfenster leer. Ich sehe mir die verlinkte Änderung an …

Zitat von aborix

Ich habe den Code auf dieser Seite von Aris gefunden und er hat ihn anscheinend von einem chinesischen Benutzer übernommen.

… und schreibe also

if (window.__SSi && window.__SSi !== 'window0') {
	return gBrowser.selectedBrowser.removeAttribute('blank');
}

… aber das ändert auch nichts.

Zitat von ArisCTR

Der Nutzer GoogleBeEvil hatte mich auf diesen Workaround hingewiesen: https://github.com/Aris-t2/CustomJSforFx/issues/14

Das sah ich mir an und bemerkte, dass dort weitere Änderungen besprochen und von Aris auch durchgeführt wurden. Aber auch ein

if (document.getElementById('main-window').getAttribute('chromehidden') {
	return gBrowser.selectedBrowser.removeAttribute('blank');
}

bewirkte nichts. Wie gesagt, alles in einer eigenen, sonst leeren (*) Skriptdatei und auch ohne jegliche Funktionsummantelung, war vorher aber auch schon so.
(*) Eigentlich: Der bisher genutzte Code steht auskommentiert davor.

Wenn man das in ein bestehendes Skript einbauen soll, wo dann: außerhalb der äußeren Funktion (wäre dann wohl effektiv dasselbe wie jetzt bei mir) oder innerhalb und im letzteren Fall an welcher Stelle? Ich nutze revertaddonbarstatusbar. Übrigens testete ich neben dem Privatfenster mit den Addons, wie ich sie vor ein paar Tagen noch erfolgreich in Re: addons zur exif-Anzeige öffnen nicht mehr eingesetzt habe.

Zitat von aborix

Ich habe es tatsächlich nicht in GM usw. getestet, sondern nur in der Webkonsole und angenommen, das genügt. :wink:

Du Schlingel! :wink:

Aber ein anderes Problem ist mir aufgefallen. Du konntest es nicht wissen und testen, weil ich nichts davon geschrieben habe: Ich nutzte bisher auch Popup ALT Attribute. Das funktioniert aber nicht mehr mit beiden Skript-Varianten von dir. Falls Du es dir mal ansehen willst, auf dieser Testseite sollte im dritten Bild (dem sehr bunten) der Alt-Text als Tooltip erscheinen. Mit den Skriptvarianten erscheint da ausschließlich die Linkadresse. Im vierten wie im zweiten Bild wird korrekt der Titel angezeigt und deshalb der Alt-Text auch mit Addon ignoriert.

Ich hatte mich übrigens schon länger gefragt, ob man das theoretisch auch per Skript erledigen könnte, dann aber sicher nur per Affen-Skript, also user.js.

Edit: O, es ist nicht ganz das, woran ich dachte, aber jemand hat tatsächlich bereits ein ähnliches Userskript geschrieben: Link Tooltips.

Zitat von aborix

Das Skript eignet sich etwas verändert auch für Greasemonkey u. dgl., es ist sogar etwas einfacher:

Code

var documentElement = document.documentElement;

Aha. Ich dachte immer, dass man Greasemonkey & Co. nur auf Webseiten anwenden kann (über @include oder @match im nicht bei dir, aber in Endoors Version vorhandenen Kommentarblock). Oder ist das genau dafür geschrieben und deshalb einfacher als das UserChrome-Skript und würde also die Tooltips nur auf Webseiten ändern?

Edit: etwas zu schnell abgeschickt – im Violentmonkey ein neues Skript angelegt, deinen Code eingefügt und gesehen, dass es tatsächlich funktioniert. OK, sonst hättest du es auch nicht gepostet …

Zitat von micha112

....exify ist anscheinend auch noch eine gute Alternative. Zeigt beim Überfahren eines Bildes mit dem Mauszeiger die wichtigsten exifs am unteren Bildrand....

Wenn dir das ausreicht, dann nimm es.

Zitat von der_nachdenklicher

Interessant: Mit Firefox 60.5.2esr und Firefox 63.0.3 funktioniert die Erweiterung.

Mit mozregression erhalte ich für die Erweiterung Exif Viewer, Version 3.7.5 folgende Meldung...

Schick das doch dem Autor als kurze Mitteilung.

Zitat von aborix

Teste dieses Skript:

Aborix, wenn ich eine Frau wäre, würde ich jetzt sagen „Du bist ein Schatz!“
Das ist genau das, was ich mir gewünscht habe. Echt danke dafür! :klasse:

Ich hab dem Skript lokal den Namen Tooltip_with_URL.uc.js gegeben.

Zitat von .DeJaVu

Der "Exif Viewer" funktioniert hier kein Stück mehr, die Infos bleiben leer, egal, wo ich reinklicke. Firefox 65/66/67 (65 mit neuem Profil getestet und einem Bild von meiner Cam)

Zum Abgleich:
Hier Fx 65, das Addon ist frisch installiert von hier: Exif Viewer, Version 3.7.5. Als Testbild dient dieses (ich habe es auch noch mit weiteren ausprobiert): Schlosspark_Babelsberg_Blick_Glienicker_Bruecke.jpg (für die Lizenz siehe folgenden Link: File:Schlosspark Babelsberg Blick Glienicker Bruecke.jpg – Wikimedia Commons). Die Addonfenster sehen dann so aus – links wxIF, rechts der Exif Viewer: (Link entfernt).

Zitat von micha112

Als addons für die Anzeige von exifs nutze ich exif viewer und Wxif. Normalerweise habe ich bisher ein Bild mit rechts anklickt und dann im Kontexmenü eins der zwei addons ausgewählt. Daraufhin öffnete sich dann ein popup mit den exifs. Seit kurzem öffnet sich aber leider kein popup mehr. In der Taskleiste wird ein neues Fenster geöffnet mit der Bezeichnung moz-extension://a9fe.... - das wars. Dieses Fenster kann man aber auch nicht öffnen um die exifs angezeigt zu bekommen. Auch eine Neuinstallation der addons brachte keine Besserung. Auf einem anderen PC mit win 10 laufen die addons weiterhin wie gewohnt.

Benutzt du zufällig ein UserChrome-Skript, das eine weitere Browserleiste installiert? Dann liegt vermutlich dort das Problem. Man muss zusätzlichen Code ergänzen, damit sich neue Fenster nicht ohne sichtbaren Inhalt öffnen. Siehe Code von Aborix in Diskussion zu userChrome-Sripts, Beitrag #2189 mit wichtiger Erläuterung am unteren Ende von Beitrag #2104 (Skriptversion dort älter).

Hier funktionierten damit sowohl wxIF als auch der Exif-Viewer, den ich noch gar nicht kannte.

Zitat von Endor

Ich kenne dieses Script hier, damit werden aber alle Tooltips angesprochen.

Das Skript funktioniert, was schon ein Unterschied zum anderen bei Ardiman zu findenden ist, aber ist nicht das, was mich interessiert. Es geht darum, dass mit dem Addon die Webadresse direkt am Mauscursor eingeblendet wird, und das in einer zweiten Zeile unterhalb des Titelattributes, das auch vom normalen Tooltip angezeigt wird (welcher bis Fx 64 unterdrückt wurde, wenn die zwei sich ins Gehege kamen). Wenn es kein Titelattribut gibt, dann wird nur die Adresse eingeblendet. Genau genommen bräuchte es das Skript aber gar nicht, weil das auch allein mit CSS geht – ich hatte ja angedeutet, dass ich die Tooltips temporär ausgeblendet hatte, nämlich mit display:none.

Zitat

Vielleicht kannst Du es Dir ja so anpassen wie Du es brauchst:

Nein, das kann ich leider nicht. Ich vermute ja, das man jemand mit Scripting-Kenntnissen den Code nehmen und adaptieren kann, der standardmäßig genutzt wird, um die Webadressen im Statusleistentooltip anzuzeigen, aber für mich ist das zu hoch.

Das Addon URL Tooltip WE funktioniert seit Fx 65 nicht mehr hundertprozentig: Die standardmäßigen Tooltips werden nicht mehr unterdrückt, sondern legen sich über den Tooltip des Addons.

Kann man das wieder reparieren (durch ergänzenden Code) oder das Addon gleich durch ein UserchromeJS-Skript ersetzen? Bei Ardiman findet man ein altes, bei mir nicht mehr funktionierendes Skript URLTooltip_mod.

Das Addon scheint keinen aktiven Autor mehr zu besitzen, so dass ich darin keine Hoffnung setze. Innerhalb des Addons findet man in der Datei content.js übrigens das hier, was wohl der nicht mehr funktionierende Code ist:

disableDefaultTooltips(nodeList) {
      // Some black magic to disable default title tooltip
      // without disturbing original "title" attribute.
      // There is no way to access to browser.chrome.toolbar_tips
      // or agent css sheet from WebExtension. =\
      if('parentTitle' in nodeList){
        if(!nodeList.length) nodeList = [nodeList.anchor];
        nodeList[0].appendChild(magicComment);
      }
/* gekürzt */
    },
    enableDefaultTooltips(nodeList) {
      if('parentTitle' in nodeList){
        if(magicComment.parentNode)
          magicComment.parentNode.removeChild(magicComment);


        if(!nodeList.length) nodeList = [nodeList.anchor];
      }
/* ebenfalls gekürzt */
    },

Meine kläglichen Versuche mit CSS funktionierten entweder zu gut (Tooltips völlig unterdrückt, dann aber überall im Browser) oder gar nicht (ich wollte den Z-Index beeinflussen, was sowieso am rechten Seitenrand nur teilweise gehen würde).

Zitat von Loewenherz

Hallo,
in meiner Systemsteuerung von Windows 7 werden mir zwei Firefox-Versionen angezeigt:
- 43.0.4
- 65.0.1

Wo in der Systemsteuerung? Unter „Programme und Funktionen“? Dann solltest Du in der Registrierungsdatenbank unter

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
  oder, wenn Du einen 64-bit-Rechner hast, unter
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

einen Schlüssel („einen Unterordner“) finden, der den Namen der Firefox-Version trägt, d. h. mit der Versionsnummer im Namen. Ich hab mal bei mir nachgeforscht und staune selber: Bei mir ist es tatsächlich „Mozilla Firefox 12.0 (x86 de)“, obwohl ich inzwischen die 64-Bit-Version nutze und auch die aktuelle Version 65.0.1 (ich installiere aber auch nicht mehr dauernd neu). Wenn wie Du sagst, bei dir für die aktuelle Version ein eigener Eintrag existiert, dann kannst du den alten Schlüssel gefahrlos löschen; vielleicht vorher eine Sicherung anlegen, also hier den Schlüssel in eine REG-Datei exportieren.

Zitat von Sören Hentzschel

Die Optimallösung wäre, das in einer Art Wiki zu pflegen, was das Einspielen von Updates einfach macht. […]

Sehe ich das richtig?

Exakt so.

Zitat von ArisCTR

addonbar.uc.js + addonbar_vertical.uc.js + dein Fix in beiden Dateien = Erweiterungen, die eigene Fenster öffnen, funktionieren.

addonbar.uc.js + addonbar_vertical.uc.js + ein weiteres Script wie space_and_separator_restorer.uc.js oder additional_top_toolbars.uc.js inklusive deines Fixes in jeder Datei = Erweiterungen, die eigene Fenster öffnen, funktionieren nicht.

(Fettmarkierung durch mich.) Aris, der Fix darf nur einmal pro Skriptsammlung eingetragen werden – entweder in einem der Skripte ergänzt oder separat als eigenes Skript. Mit Aborix’ Worten:

Zitat von aborix

Man kann den Code in ein eigenes Skript geben oder in ein anderes einfügen. Er soll nur einmal ausgeführt werden und daher wenn, dann in nur einem Skript, hinzugefügt werden.

Nebenbei: Aborix’ Vorgabe von 1500 ms funktioniert hier gut, 1000 ms waren dagegen zu kurz.

Zitat von milupo

Und was hältst du für die Originalquelle? Ich kenne nur die Seiten von Ardiman und Endor und wenn die noch nicht aktualisiert sind, weil es, wie wir gesehen haben, auch mal sein kann, dass Skripte aufhören zu funktionieren. An anderer Stelle habe ich dir ja auch grundsätzlich recht gegeben, nur ist dein Tipp nicht immer machbar.

Ja, „Originalquelle“ ist unsauber formuliert, weil ein erheblicher Anteil der Skripte bei Ardimn/Endor übersetzte Versionen chinesischen oder japanischen Ursprungs sind. Ich meinte schon Ardiman/Mithrandir oder Endor (ursprünglich war es ja so, dass Endor aktualisierte Versionen zu Mithrandir rübergeschoben hat, bitte hier nicht an technischen Details aufhängen). Wenn, wie zuletzt oft geschehen, hier im Forum eine neuere Version präsentiert wurde, dann kann man auf diese verlinken. Das sollte es auch Endor oder Mithrandir leichter machen, wenn sie die Zeit finden sollten, selbst die Updates einzupflegen.

Zitat von milupo

Ich krieg die Krise - ich wusste gar nicht, dass Aris auch ein Skriptprojekt hat.

Ich hatte hier im Thread einst (vor dem Großen Vaterländischen Krieg) darauf hingewiesen … 

Dann mal schnell die Gelegenheit genutzt, auf diese hinzuweisen:

• Alice0775, japanisch, Quelle vieler bekannter Skripte.
• Harv, chinesisch, mindestens OpenNewTab bei Ardiman ist eigentlich von dort.

Zitat von milupo

Was verstehst du unter "dieser Aktualisierung"?

Ich beziehe mich doch auf Deine Antwort. Ich meine also, man sollte auf das Posting verlinken, wo die „funktionierende Skriptversion“ zuerst präsentiert wurde.

Zitat von Sören Hentzschel

Ich hab mir nicht abgesehen, ob var vs. let hier ein Problem ist, aber wenn das Thema schon aufkommt, hier eine Erklärung zum Unterschied mit Beispielen:

https://stackoverflow.com/a/11444416

Ah, der Scope ist die Funktion. Die umschließende Funktion der Skripte verhindert also, dass die Variablen sich trotz gleichen Namens Konkurrenz machen. Mit etwas längerem Nachdenken hätte ich darauf kommen können, dass die Skripte sonst auch schon mit der bisherigen Schreibweise nicht gemeinsam hätten funktionieren dürfen.

Zitat von milupo

Im Grunde genommen hast du recht, nur gibt es da einen Haken: Die Skripts an den Originalquellen (ardiman und Endor8) sind nicht immer aktualisiert bzw. angepasst und die funktionierenden Skriptversionen gibt es dann nur irgendwo im Forum.

Dann verlinkt man auf diese Aktualisierung.

Zitat von 2002Andreas

Wenn ich das mache, also new-toolbar unten gegen tb.id austauschen, dann habe ich zwar auch eine Leiste unten, aber in die kann ich keine Icons reinschieben. :-??

Dann muss bei dir etwas anderes nicht in Ordnung sein. Oder … ersetze in den Skripten mal var mit let. Ersteres ist, wie hier im Forum irgendwann schon einaml von Sören global, so dass sich die verschiedenen tb.id ins Gehege kommen können.

Zitat von milupo

Außerdem, wir reichen Skripte so oft weiter an Benutzer, die sie verwenden wollen, wir müssten jedes Mal sagen, das und das Skript brauchst du auch noch, damit das eine Skript funktioniert. Wir reden hier nur von zwei Skripten, zu denen dann ein drittes dazu käme, aber wer weiß, ob das dann nicht auch mehr sein können.

Tja, da wäre mein Tipp, immer (nur) auf die Originalquelle zu verlinken, dann sinnvoll …

Zitat von aborix

Ein Workaround für normale als auch von Erweiterungen geöffnete neue Fenster ist möglicherweise folgender Code.

Oooh, ich war schon dabei, eine Frage dazu zu stellen. Davon war übrigens auch der Privatmodus betroffen, da er ja auch ein eigenes Fenster öffnet. Schrägerweise funktionierten die Links noch (wenigstens der Tooltip bei Mausover) und anscheinend auch die Textfelder als solche, sofern vorhanden, wenigstens änderte sich der Cursor in diese Richtung.

Zitat von 2002Andreas

Teste bitte mal dieses Script:

Code

tb.id = 'new-toolbar';
  // […]
  CustomizableUI.registerArea('new-toolbar', {legacy: true});

Zitat von milupo

Diese Skript fügt oben eine Leiste ein:

Code

var tb = document.createElement('toolbar');
tb.id = 'fp-statusbar-2';
// […]
CustomizableUI.registerArea( 'fp-statusbar-2' , { legacy: true } );

Dieses unten:

Code

tb.id = 'new-toolbar';
  // […]
  CustomizableUI.registerArea('new-toolbar', {legacy: true});

Und dieses ebenfalss unten:
[…]

Es wäre besser, in Zukunft nur noch meine in Beitrag #288 gezeigte Änderung zu propagieren, denn bisher muss der Wert der Toolbar-ID zweimal eingegeben werden (vgl. oben das, was ich stehen gelassen habe), mit der Änderung dagegen nur noch einmal direkt in der Variablendeklaration. In den hier zitierten Fällen würde die jeweils drittletzte Zeile im Skript (ohne Klammern die vorletzte) dann so lauten

CustomizableUI.registerArea(tb.id, {legacy: true});

(Und um es hier auch noch einmal zu erwähnen: Ich hielte es für besser, statt immer und immer wieder alles nur zu kopieren, was meiner Ansicht nach zu immer mehr Unübersichtlichkeit führt, für die Skripte immer nur zur Originalquelle zu verlinken, was auch ein Posting mit einer Aktualisierung hier im Forum sein kann; in solchen Fällen speichere ich mir die Links immer mit im Skript ab.)

Danke für den Thread. Mir war das auch sehr störend aufgefallen, aber ich war noch nicht so weit gekommen, den Verursacher festzustellen.

Ich benutzte ja das Skript von Mithrandir/Ardiman: OpenNewTab.uc.js, Dort ist die Originalquelle verlinkt und wenn man dorthin geht, gibt es ebenso ein Update (und anscheinend zwischendurch schon weitere). Siehe openNewTab.uc.js. Der Vorteil des Skripts von Harv ist, dass man dort einzelne Teilfunktionen per Variable aktiv („true“) oder inaktiv („false“) setzen kann.