Firefox 2 kennt window.external

[Cheatah]

Hi,

bisher war für solch groben Unfug wie "Seite zu den Favoriten hinzufügen" oder "zur Startseite machen" window.external das ideale[tm] Prüfobjekt: Nur diejenigen Browser, die solchen Quatsch beherrschen, der zudem über window.external-Methoden durchgeführt wird, kannten das Objekt. Die Methoden direkt zu prüfen schied u.U. aus, weil dem IE erst Benehmen eingeprügelt, sprich: per behavior-Eigenschaft die Methode bekannt gemacht werden musste.

Soweit, so gut.

Auf einer gewissen Portal-Startseite habe ich auch Entsprechendes gemacht: Wenn Objekt vorhanden, dann biete Quatsch an. Das ging ein Weilchen gut. Mit Erstaunen musste ich nun aber feststellen, dass Firefox 2 im Footer der Seite einen Link "zur Startseite machen" anbot. Grund: Er kennt das Objekt. Die entsprechenden Methoden stehen natürlich nicht zur Verfügung, der Link war also völlig fehl am Platz. Nun, ich konnte das Problem beheben, indem ich die Prüfung durch "if (UserAgent.isIe())" ersetze, aber das ist mir zu ... indirekt. Schließlich geht es nicht darum, IE-User zu veralbern, sondern um die Fähigkeit, eine Seite zur Browser-Startseite zu machen.

Das Schlimmste an der Geschichte ist aber, dass window.external bei Mozilla weitgehend undokumentiert zu sein scheint. Ich finde nichts in den Release-Notes, und im Developer Center lautet der offenbar einzige Hinweis "Adding search engines from web pages". Das kann's doch nicht sein, oder? Wo um alles in der Welt ist dieses JavaScript-Objekt dokumentiert? Was kann es, welche Schnittstellen hat es, welche Informationen liefert es unter welchen Bedingungen? Wo finde ich all dies?

Und: Wie frage ich nun sinnvollerweise ab, ob der Browser so dämlich ist, die eingestellte Startseite manipulieren zu lassen?

Cheatah

[Siechfred]

Hell-O!

Das Schlimmste an der Geschichte ist aber, dass window.external bei Mozilla weitgehend undokumentiert zu sein scheint.

Mir scheint, dass die Unterstützung von window.external als Bug einzustufen ist, schau dir mal die entsprechende Bug-Liste an.

Und: Wie frage ich nun sinnvollerweise ab, ob der Browser so dämlich ist, die eingestellte Startseite manipulieren zu lassen?

Mache es mal testweise so, wie ich es in meinem Schnipselchen getan habe. Oder nimm für den IE-spezifischen Code einen Wert für das type-Attribut, das nur der IE akzeptiert, z.B. "text/jscript". Mal ein kleines Beispiel:

<script type="text/jscript">  
function bar() {  
  alert("bar");  
}  
</script>  
<script type="text/javascript">  
function foo() {  
  if(typeof window['bar'] != 'function')  
    alert("Nix bar");  
  else  
    bar();  
}  
</script>

Was Mozilla 2 draus macht, kann ich hier leider nicht testen.

Siechfred

[Siechfred]

Das Schlimmste an der Geschichte ist aber, dass window.external bei Mozilla weitgehend undokumentiert zu sein scheint.
Mir scheint, dass die Unterstützung von window.external als Bug einzustufen ist, schau dir mal die entsprechende Bug-Liste an.

Noch ein Nachsatz: Die Unterstützung von window.external.AddSearchProvider() ist wohl nur für die Entwicklung von Erweiterungen gedacht, indes scheint der Browser nicht zwischen dem JS-Einsatz in diesem Kontext und in Webseiten eingebettetem Javscript unterscheiden zu wollen.

Siechfred

[Cheatah]

Hi,

Mir scheint, dass die Unterstützung von window.external als Bug einzustufen ist, schau dir mal die entsprechende Bug-Liste an.

hm. Hatte ich das jetzt befürchtet oder gehofft? :-)

Mache es mal testweise so, wie ich es in meinem Schnipselchen getan habe. Oder nimm für den IE-spezifischen Code einen Wert für das type-Attribut, das nur der IE akzeptiert, z.B. "text/jscript".

Sind beides gute Gedanken. Der letztere ähnelt ein bisschen der Prüfung auf UserAgent.isIe(), aber die Kenntnis um eine behavior-Eigenschaft ist ziemlich genau das, worum es bei der Funktion geht. Danke für diese Idee!

Was Mozilla 2 draus macht, kann ich hier leider nicht testen.

Meinst Du Seamonkey, oder wolltest Du "Firefox 2" schreiben?

Cheatah

[Siechfred]

Hell-O!

Was Mozilla 2 draus macht, kann ich hier leider nicht testen.
Meinst Du Seamonkey, oder wolltest Du "Firefox 2" schreiben?

Klar meinte ich Firefox 2. Da sind wohl die, ähm, Seeaff^Wpferdchen mit mir durchgegangen ;-)

Siechfred

[Cybaer]

Hi,

Sind beides gute Gedanken. Der letztere ähnelt ein bisschen der Prüfung auf UserAgent.isIe(),

Also wenn es so "brutal" sein darf, dann kannst Du IMHO auch gleich Conditional Compilation nehmen.

Gruß, Cybaer

[Tim Tepaße]

Hallo Siechfred,

Mir scheint, dass die Unterstützung von window.external als Bug einzustufen ist, schau dir mal die entsprechende Bug-Liste an.

Ich würde es nicht als Fehler ansehen, sondern als Versuch der Kompabilität mit dem IE. Wieso das Rad neu erfinden, wenn man die Bookmarkfähigkeit durch [code lang=javascript]window.external.AddFavorite()[code] existiert. Und warum das Rad neu erfinden, wenn der IE 7 die offene und freie OpenSearch-Spezifikation von Amazon implementiert, man das auch machen will und einfach die APIs nach dem Vorbild des IE7 gestalten kann? Schliesslich ist es _ein_ Web, man muss ja nicht zwanghaft das Rad neu und anders erfinden.

Tim

[Cybaer]

Hi,

Ich würde es nicht als Fehler ansehen, sondern als Versuch der Kompabilität mit dem IE. Wieso das Rad neu erfinden, wenn man die Bookmarkfähigkeit durch [code lang=javascript]window.external.AddFavorite()[code] existiert.

Das sehe ich auch so (man denke nur an innerHTM oder XMLHttpRequest). Nur: Genau das macht FF2 ja *nicht*! Wenn FFs external die Methode Addfavorite() hätte, hätte Cheatah ja nicht das Problem (sondern FF2-Nutzer nur ein Feature mehr auf der Site).

Gruß, Cybaer

[Tim Tepaße]

Hallo,

Nur: Genau das macht FF2 ja *nicht*! Wenn FFs external die Methode Addfavorite() hätte, hätte Cheatah ja nicht das Problem

Ja, aber das heisst ja nicht, dass external „alles“ anbieten muss, was es so gibt. Ich kann ja auch nicht aus dem Vorhandensein des globalen Objektes window schliessen, dass es ein Attribut window.opera hat. Oder von dem Vorhandensein von document darauf schliessen, dass es document.all oder sagen wir mal document.matchSingle() implementiert hat. Man muss schon genau das überprüfen, was man sucht – das ständige Leid in JS/DOM. ;)

Tim

[Cybaer]

Hi,

Ja, aber das heisst ja nicht, dass external „alles“ anbieten muss, was es so gibt.

War aber nicht schlecht. ;)

Man muss schon genau das überprüfen, was man sucht – das ständige Leid in JS/DOM. ;)

Full ACK. :)

Gruß, Cybaer

[Siechfred]

Hell-O!

Mir scheint, dass die Unterstützung von window.external als Bug einzustufen ist, schau dir mal die entsprechende Bug-Liste an.
Ich würde es nicht als Fehler ansehen, sondern als Versuch der Kompabilität mit dem IE. Wieso das Rad neu erfinden, wenn man die Bookmarkfähigkeit durch [code lang=javascript]window.external.AddFavorite()[code] existiert. Und warum das Rad neu erfinden, wenn der IE 7 die offene und freie OpenSearch-Spezifikation von Amazon implementiert, man das auch machen will und einfach die APIs nach dem Vorbild des IE7 gestalten kann? Schliesslich ist es _ein_ Web, man muss ja nicht zwanghaft das Rad neu und anders erfinden.

Das, was die Unterstützung von window.external m.E. zum Bug macht, ist, dass eine Objektabfrage dem Client Vorhandensein vorgaukelt, obwohl lediglich ein einziges Feature umgesetzt wurde, nämlich die von Cheatah genannte Methode AddSearchProvider (siehe hierzu MSDN: external-Object und die erst ab IE7 verfügbare Methode AddSearchProvider). Die übrigen Eigenschaften und Methoden von window.external werden m.W.n. von Firefox 2 nicht umgesetzt (auch nicht AddFavorite). Und da die entsprechende Funktionalität - wie ich bereits schrieb - eigentlich nur für die Entwicklung von Erweiterungen gedacht ist, erachte ich die kontextunabhängige Verfügbarkeit des external-Objektes für einen Bug. Die Gecko-Engine kocht in vielerlei Hinsicht ihr eigenes Süppchen und bietet Methoden und Eigenschaften an, die in Nicht-Geckos nicht funktionieren. Ich halte es deshalb von den Entwicklern für inkonsequent, wegen einer einzigen Methode ein derart komplexes Objekt einzuführen, wenn es auch eine proprietäre Variante getan hätte. IE-Kompatibilität hat doch noch nie interessiert, warum jetzt auf einmal?

Siechfred

[Tim Tepaße]

Hallo Siechfred,

Das, was die Unterstützung von window.external m.E. zum Bug macht, ist, dass eine Objektabfrage dem Client Vorhandensein vorgaukelt, obwohl lediglich ein einziges Feature umgesetzt wurde [...]

Wenn ein Objekt auch nur eine Methode ist es nunmal als Objekt vorhanden. ;)

Und da die entsprechende Funktionalität - wie ich bereits schrieb - eigentlich nur für die Entwicklung von Erweiterungen gedacht ist [...]

Wenn Du Erweiterungen im Sinne von Firefox-Erweiterungen meinst: Nein. AddSearchProvider ist schon für den Inhalt von Webseiten gedacht.

Um etwas Erklärung zu geben: Opensearch ist eine Spezifikation für ein Beschreibungsformat und die – für Browser aber weniger relevante – Ausgabe von Websuchen. Im ganz kleinen hat das den Effekt dass man für das Benutzen von Websuchen nicht mehr Firefox oder eine Firefox Erweiterung oder, wäre es schon bei Opera integriert irgendeine *.ini editieren muss, sondern, dass die Suche automagisch benutzbar ist. AddSearchProvider erlaubt es so ein Suchinterface dauerhaft zu installieren: „Möchten Sie die SELFHTML Suche dauerhaft in ihrem Browser installieren?“ (Nein, für die SELFHTML Suche gibt's noch kein Opensearch Interface).

[...] erachte ich die kontextunabhängige Verfügbarkeit des external-Objektes für einen Bug.

Wenn das nun im Kontext einer normalen Webseite ausgeführt werden soll, kann man das schlechterdings auf einen Kontext beschränken, den man findet keinen. Der einzige Fall, den ich mir aus den Fingern saugen kann, wäre es, die Verfügbarkeit eines mit Opensearch Autodiscovery eingebundenen Opensearch-Interfaces. Allerdings wäre das auch nicht allgemein, in einem Verzeichnis verschiedener Opensearch-Interfaces, aus denen man das passende installiert, wäre das wieder absurd.

Ich halte es deshalb von den Entwicklern für inkonsequent, wegen einer einzigen Methode ein derart komplexes Objekt einzuführen, wenn es auch eine proprietäre Variante getan hätte.

Sieh es nicht als komplexeres Objekt hat. Sieh es einfach als Namensraum an, der es ermöglicht eine Methode browserübergreifend aufzurufen, anstatt das ganze wieder dämlich abstrahieren zu müssen. Das besänftigt den Schlaf in der Nacht. ;)

Tim

[molily]

Hallo,

bisher war für solch groben Unfug wie "Seite zu den Favoriten hinzufügen" oder "zur Startseite machen" window.external das ideale[tm] Prüfobjekt

Zu den Favoriten hinzufügen geht mit window.external.AddFavorite, wieso soll dann window.external das ideale Prüfobjekt sein? window.external.AddFavorite wäre das ideale Prüfobjekt gewesen. Von window.external auf window.external.AddFavorite zu schließen, ist zwar naheliegend, aber letztlich unsauber. Eine - wenn auch zunächst überkorrekt scheinende - Objektabfrage kann dies verhindern.

Nun, ich konnte das Problem beheben, indem ich die Prüfung durch "if (UserAgent.isIe())" ersetze

Was ist gegen if (window.external && window.external.AddFavorite) einzuwenden?

Schließlich geht es nicht darum, IE-User zu veralbern, sondern um die Fähigkeit, eine Seite zur Browser-Startseite zu machen.

Das ist eine andere Geschichte. »Zur Startseite hinzufügen« läuft so ab:
Ein Element bekommt .style.behavior = 'url(#default#homepage)' und dann wird dessen Methode setHomePage ausgeführt.
Ergo, window.external hat damit nichts zu tun. Man kann z.B., wie Siechfred sagt, prüfen, ob .style.behavior existiert (d.h. ein leerer String ist oder eben undefined). Danach kann man noch, bevor der Link überhaupt auftaucht, prüfen, ob die Methode setHomePage existiert.

Mathias

[Cheatah]

Hi,

Zu den Favoriten hinzufügen geht mit window.external.AddFavorite, wieso soll dann window.external das ideale Prüfobjekt sein?

ganz einfach: Weil "if (window.external && window.external.AddFavorite)" eine Exception schmeißt. Gut, ich kann natürlich den typeof() gegen "unknown" prüfen, aber das widerstrebt mir dermaßen, dass ich schon vom Gedanken Schüttelfrost bekomme.

Das ist eine andere Geschichte. »Zur Startseite hinzufügen« läuft so ab:

Danke, der Vorgang ist mir im Großen und Ganzen klar :-)

Ergo, window.external hat damit nichts zu tun.

Mit setHomepage() nicht, das stimmt. Danke für Dein Feedback!

Cheatah

[molily]

Hallo,

Weil "if (window.external && window.external.AddFavorite)" eine Exception schmeißt.

Oh, tatsächlich. Dann nimmt man die sichere Allround-Objektabfrage typeof() == "undefined" zum Ausschluss derjenigen Browser, die AddFavorite nicht kennen.

Gut, ich kann natürlich den typeof() gegen "unknown" prüfen

Mit typeof sollte man bestenfalls nur negativ testen, also if (typeof(...) == "undefined") return;, denn wenn IE in Zukunft irgendwann doch ECMAScript implementiert und typeof() bei einer Methode korrekterweise "function" anstatt "object", "unknown" usw. liefert, dann ist die Weiche defekt.

Mathias