[Ext] Ubiquity

Schwachsinnig ist gegenwärtig aber, dass abonnierte Kommandos über Annotations in Places gespeichert werden. Sobald der URL aus der History verschwindet (sei es manuell oder automatisch), ist das Abo weg. *grmpf* "Durchdacht" ist etwas anderes.

Bis das ganze einen akzeptablen Status erreicht, dauert es wohl noch ein wenig. Auch stört, dass die Default-Kommandos nur umständlich durch Editieren der betreffenden Dateien zu entfernen sind. Man könnte noch einige weitere Kritikpunkte nennen. Ich sehe darin durchaus Potential und werde die Erweiterung wohl auch nutzen, allerdings ist das gegenwärtig nur für Schrauber zu empfehlen!

SmurFy
https://wiki.mozilla.org/Labs/Ubiquity/Skins/
Vielleicht hilft das etwas weiter bei der optischen Anpassung, bin gerade darüber gestolpert.

Dankeschön! Habs mal getestet und Schwupp habe ich sogar meinen Style, welchen ich auch auf meiner HP habe, zusammengebastelt!

[Blockierte Grafik: http://img3.imagebanana.com/img/k16bbhzv/thumb/Aufnahme5.png]

Was soll eigentlich der Bockmist, dass sich Ubiquity ungefragt an den UA dran hängt? So was sorgt doch nur für Probleme in Verbindung mit schlecht implementierten Browser-Erkennungsroutinen. Der Sinn erschließt sich mir überhaupt nicht. Wenn man bei den Kommandos Request absetzt, dann kann man auch einen beliebigen UA mitsenden.

Ergänzung:
Und dann noch so penetrant, dass man den Ubiquity-Code editieren muss, um den Käse wieder los zu werden.

In ubiquity@labs.mozilla.com/feed-parts/body/en/builtincmds.js

function startup_openUbiquityWelcomePage()
{
  const VERSION_PREF ="extensions.ubiquity.lastversion";
  const USERAGENT_PREF = "general.useragent.extra.ubiquity";


  var ext = Application.extensions.get("ubiquity@labs.mozilla.com");


  var expectedPref = "Ubiquity/" + ext.version;
  if (Application.prefs.getValue(USERAGENT_PREF, "") != expectedPref)
    // Prevent user agent override
    //Application.prefs.setValue(USERAGENT_PREF, expectedPref); <-- HIER AUSKOMMENTIEREN


  // Compare the version in our preferences from our version in the
  // install.rdf.
  var currVersion = Application.prefs.getValue(VERSION_PREF, "firstrun");
  if (currVersion != ext.version) {
    Application.prefs.setValue(VERSION_PREF, ext.version);
    cmd_help();
  }
}

Weil ich gerade damit rumspiele noch ein paar Bemerkungen:

- Das Auto-Update-Feature ist zwar nett, aber alles andere als sicher. Code-Updates laufen völlig unbemerkt ab, man wird nicht darauf hingewiesen. Code den man mal beim Subscribe-Vorgang geprüft hat, kann komplett ausgetauscht werden. Da die Rechte von Ubi-Skripts gegenwärtig die selben wie die des Browser-Prozesses sind, werden diese nur noch durch die Limitierungen des Systems beschränkt. Eine "Freude" wenn der User als "Admin" arbeitet.

- Die Update-Pings werden bei jeder Aktivierung der Ubi-Oberfläche abgesetzt. Modulo Cache ist das natürlich ziemlich unnötiger Traffic. Ein Update pro Fx-Session sollte eigentlich ausreichend sein.

- Auto-Updates über http ist natürlich in offenen Netzen ein Ansatz für MitM.

- Da inzwischen Ubi-Skripts auch bei pageLoad_ und startup_ ausgeführt werden können, öffnet das zwar grandiose Möglichkeiten Erweiterungen durch kleine Hacks zu ersetzen, führt aber auch die Problematik ein, dass Skripts nicht mehr manuell durch den User angestoßen werden müssen, ob Schaden zu verursachen.

Daher sollte man wirklich jedes Skript genau prüfen, insbesondere wenn es pageLoad_ und startup_ Funktionen enthält. Auf die Auto-Update-Funktion sollte man verzichten.

Es ging nur um die Dokumentation des gegenwärtigen Status.

http://labs.toolness.com/trac/ticket/115
http://labs.toolness.com/trac/ticket/492

Hab das Teil bisher nur in nem Testprofil laufen, da ich noch keinen wirklichen Überblick über die Funktionen hab.

Kann man da auch Schlüsselwörter aus der Suchleiste benutzen und wenn ja, wie?

Zitat

Schlüsselwörter aus der Suchleiste

Was genau meinst du damit?

Na, ich gebe zB "g test" für eine Googlesuche ein und ab dafür

Am besten auch im Stil von CyberSearch, so dass gleich die direkten Treffer angezeigt werden. Irgendjemand hatte das im CS-Thread mal erwähnt, dass er das lieber mit Ubiquity macht.

Und das geht in der Suchleiste? Wusste ich noch gar nicht...

Sowas kannst du natürlich mit Ubiquity machen. Musst eben das entsprechende Kommando g nennen.

äh, natürlich meinte ich die url-bar. Die Schlüsselwörter für eine Suche werden aber doch in der Suchleiste bzw. dessen Suchplugins abgespeichert (oder meinetwegen auch als Lesezeichen) - ich dachte das wäre klar.
Und natürlich will ich Ubiquity nicht darauf reduzieren, Aber ich dachte, das geht damit auch. Hab grad mal nachgeguckt, Ich bezog mich auf diesen Beitrag von SmurFy: http://www.firefox-browser.de/forum/viewtopi…p=495135#495135
Den hatte ich noch im Hinterkopf und wollte das deshalb irgendwann mal für Ubiquity angehen. Evtl., um mittelfristig auf CyberSearch zu verzichten. Aber naja, wenn ich dann für jedes Schlüsselwort ein eigenes Kommando anlegen muss, ist das doch ein wenig nervig.

Zitat

Aber naja, wenn ich dann für jedes Schlüsselwort ein eigenes Kommando anlegen muss, ist das doch ein wenig nervig.

Musst du nicht, du kannst auch eines anlegen mit bspw. dem Namen such. Dann übergibst du dem Kommando zwei Parameter, den einen für dein gewünschtes Schlüsselwort (bspw. g) und dann noch den Suchbegriff.

such g Firefox - könnte dann nach Firefox bei Google suchen
such w Firefox - bei Wikipedia
...

Natürlich kannst du such auch zu s verkürzen oder eine Suchfunktion implementieren, die verschiedene Suchseiten auf einmal mit dem Begriff füttert und in Tabs öffnet.