none
IE8 Zwischenablage im JavaScript gesperrt. RRS feed

  • Frage

  • Hallo,

    ich habe für den Internet Explorer folgendes Zusatzmenü implementiert:

    [Link mit Titel in die Zwischenablage]
    http://www.dzaebel.net/LinkTitle.htm

    Das funktionierte bisher sehr gut. Seit der Installation des IE8 (auf Vista Ultimate SP1) nicht mehr, das Menü erscheint, aber die Zwischenablage wird nicht gefüllt. 

    Was ist "best practice", um die Installationsroutine so anzupassen, dass die Zwischenablage wieder wie sonst gefüllt wird?


    ciao Frank
    http://Dzaebel.NET

    ciao Frank
    • Bearbeitet Frank Dzaebel Montag, 6. April 2009 10:10 Fehlerkorrektur
    Montag, 6. April 2009 10:07

Antworten

  • oh, da hat sich MSFT selber einen Antwort-Haken gegeben / ich war's jedenfalls nicht :-)


    > ... keine Javascript-Datei, sondern eine HTML-Datei ...

    nein, das ist keine gültige HTML-Datei, genausowenig, wie eine gültige JavaScript-Datei.
    Auch durch das Ändern der Dateinamenserweiterung in ".htm" wird diese Datei nicht zu einer HTML-Datei. Trotzdem zum Test hier validiert, Ergebnis: negativ, keine HTML-Datei:

    [HTML/XHTML/XML/WML Validierungsservice]
    http://validator.de.selfhtml.org/validate

     


    > ... möglicherweise mit einer anderen Anwendung verknüpft,

    es ist ja schon mal gut, dass "möglicherweise" gesagt wird, denn meine Tests auf Vista zeigen etwas anderes. Ich kann da sogar
    "LinkTitle.murks" wählen und es funktioniert. Der Grund muss also ggf. woanders liegen. Auch wird das hier in dem Beispiel nicht über
    WSH ausgeführt.

     

    > Die Dokumentation in der MSDN Library scheint vollständig zu sein, was würde eine "Best Practice" ergänzen sollen?

    vielleicht wäre eher "widersprüchlich" das richtige Attribut. Liest man in der Doku:

    [Adding Entries to the Standard Context Menu]
    http://msdn.microsoft.com/en-us/library/aa753589.aspx

    so sieht man:
       gleich am Anfang:    "... that executes a script specified by a URL."
       später dann:           "... "the page that contains the script"

    Was es nun genau ist, geht daraus IMHO nicht klar hervor.
    Vor allen Dingen nicht die erlaubte/spezifizierte Syntax oder Extension dieser Datei.
    Wäre das die einzige Doku dazu, wären Probleme im wahrsten Sinne des Wortes "vorprogrammiert".

    Nun, ich habe aber jetzt eine bessere Doku gefunden:

    [Wie Hinzufügen den Kontextstandardmenüs von dem WebBrowser Steuerelement]
    http://support.microsoft.com/kb/177241

    Hier wird zumindest "HTM" als Extension-Beispiel benutzt.
    Zitat dort: "Die URL wird in einem ausgeblendeten HTML-Dialogfeld geladen,
                      alle Inline-Skript wird ausgeführt und das Dialogfeld wird geschlossen."

    Zusätzlich werde ich die dortige Anregung nutzen und das defer-Attribut:

    [Scripts in HTML documents - defer]
    http://www.w3.org/TR/html4/interact/scripts.html#adef-defer

    [About the Browser]
    http://msdn.microsoft.com/en-us/library/aa741313(VS.85).aspx#Adding_to_the_Standa

    zufügen, sodass der "user agent" weiss, dass das Script keinen Dokument Inhalt erzeugt, sodass der Agent weiter parsen und rendern kann.
    Auch, wenn die Beispiele "htm" benutzen, so geht auch daraus nicht hervor, welche erlaubten Extensions hier möglich sind.
    ________

    Als weiteres ist noch die Virtualisierung von HKLM/Software zu beachten, denn in Wirklichkeit landen die Registry-Werte in einem VirtualStore unterhalb von HKCU, da ich die Installer-Detection durch den "accent grave" in Instàller ausgetrickst habe. Würde es mit einem requireAdministrator-Manifest installiert, so würde es nicht virtualisiert und real in die HKLM-Registry geschrieben und ggf. Probleme wie unten aufgeführt, vermieden:

    [UAC References]
    http://msdn.microsoft.com/en-us/library/bb756883.aspx

    [Martin’s Blog » Der VirtualStore und seine Schattenseiten]
    http://blog.m-ri.de/index.php/2007/02/10/der-virtualstore-und-seine-schattenseiten/

    Leider weiss ich immernoch nicht, ob es hier eine "best practice" gibt, es gäbe ggf. auch ClipBoard-Berechtigungen zu berücksichtigen. Dennoch reicht mir jetzt der augenblickliche Stand erstmal, bis sich der nächste User bei mir meldet, dass es nicht bei seinem Browser funktioniert. Also betrachten wir das ganze hier also als abgeschlossen. Danke für die Mitstreiter.


    ciao Frank
    • Bearbeitet Frank Dzaebel Mittwoch, 15. April 2009 19:00 UAC-Thematik zugefügt
    • Als Antwort markiert Mathias Schiffer Sonntag, 19. April 2009 19:37
    Mittwoch, 15. April 2009 18:03

Alle Antworten

  • Die Installationsroutine ist völlig OK. Aber ersetze mal bei Dateierweiterung und Registry-Eintrag das .js durch .htm. Besser, oder?

    Montag, 6. April 2009 16:45
  • das ist ja anonym hier - ohne Ansprechpartner :-(

    Nun hatte ich nach "best practice" gefragt, so halte ich den Hinweis,
    eine Javascript-Datei nach "htm" umzubenennen für nicht gut.

    Es wird sicher eine saubere Methode geben, das mit js umzusetzen.
    Trotzdem danke, für die Mühe.


    ciao Frank
    Dienstag, 7. April 2009 07:15
  • Was Du da hast ist keine Javascript-Datei, sondern eine HTML-Datei, in deren (unvollständiges) Dokument ein Script eingebettet ist. Auch durch das Ändern der Dateinamenserweiterung in ".js" wird eine HTML-Datei mit Javascript nicht zu einer Javascript-Datei. Ihr Inhalt wird dann nur für ein isoliertes Starten möglicherweise mit einer anderen Anwendung verknüpft, die ihrerseits möglicherweise mit solchem Inhalt gar nichts anzufangen weiß. So wie hier mit dem WSH, der im Normalfall mit der Dateinamenserweiterung .js verknüpft ist. Ein WSH-Script für diesen Zweck erstellen zu wollen scheint laut Deinem Quellcode aber nicht Deine Absicht zu sein, und wäre angesichts der deutlich einfacheren Alternativen auch nicht klug.

    Die Dokumentation in der MSDN Library scheint vollständig zu sein, was würde eine "Best Practice" ergänzen sollen? Die Dokumentation spricht übrigens im konkreten Fall für den Ziel-URL im Default-Schlüssel von "the page that contains the script".

    Dienstag, 7. April 2009 09:53
  • das ist ja anonym hier - ohne Ansprechpartner :-(

    ...


    ciao Frank

    Hallo Frank,

    Unter dem Foren-Namen steht Dir das Entwickler- und IT-Forenteam von Microsoft Deutschland mit Technologietipps und ersten Lösungsansätzen aus den Weiten von MSDN Online, TechNet Online oder auch anderen Lösungsanbietern zur Seite. Eine weitergehende technische Unterstützungsleistung ist in diesem Rahmen leider nicht möglich. Es hat auch noch weitere Vorteile so einen generischen Account zu haben. Es steckt auf jeden Fall ein Mensch dahinter :)

    Diese Foren / dieses Forum beinhaltet keinen technischen Support seitens Microsoft, sondern soll eine Online-Platform basierend auf dem Community-Prinzip „Entwickler helfen Entwickler“ darstellen. Die Mitarbeiter von MSDN Deutschland geben sich auch selbstverständlich, so wie ich jetzt hier, ganz normal zu erkennen.

    Wollte es nur erklären, damit kein Unmut entsteht oder Unklarheit.

    Viele Grüße,
    Kay


    http://www.giza-blog.de/
    Dienstag, 7. April 2009 14:31
  • oh, da hat sich MSFT selber einen Antwort-Haken gegeben / ich war's jedenfalls nicht :-)


    > ... keine Javascript-Datei, sondern eine HTML-Datei ...

    nein, das ist keine gültige HTML-Datei, genausowenig, wie eine gültige JavaScript-Datei.
    Auch durch das Ändern der Dateinamenserweiterung in ".htm" wird diese Datei nicht zu einer HTML-Datei. Trotzdem zum Test hier validiert, Ergebnis: negativ, keine HTML-Datei:

    [HTML/XHTML/XML/WML Validierungsservice]
    http://validator.de.selfhtml.org/validate

     


    > ... möglicherweise mit einer anderen Anwendung verknüpft,

    es ist ja schon mal gut, dass "möglicherweise" gesagt wird, denn meine Tests auf Vista zeigen etwas anderes. Ich kann da sogar
    "LinkTitle.murks" wählen und es funktioniert. Der Grund muss also ggf. woanders liegen. Auch wird das hier in dem Beispiel nicht über
    WSH ausgeführt.

     

    > Die Dokumentation in der MSDN Library scheint vollständig zu sein, was würde eine "Best Practice" ergänzen sollen?

    vielleicht wäre eher "widersprüchlich" das richtige Attribut. Liest man in der Doku:

    [Adding Entries to the Standard Context Menu]
    http://msdn.microsoft.com/en-us/library/aa753589.aspx

    so sieht man:
       gleich am Anfang:    "... that executes a script specified by a URL."
       später dann:           "... "the page that contains the script"

    Was es nun genau ist, geht daraus IMHO nicht klar hervor.
    Vor allen Dingen nicht die erlaubte/spezifizierte Syntax oder Extension dieser Datei.
    Wäre das die einzige Doku dazu, wären Probleme im wahrsten Sinne des Wortes "vorprogrammiert".

    Nun, ich habe aber jetzt eine bessere Doku gefunden:

    [Wie Hinzufügen den Kontextstandardmenüs von dem WebBrowser Steuerelement]
    http://support.microsoft.com/kb/177241

    Hier wird zumindest "HTM" als Extension-Beispiel benutzt.
    Zitat dort: "Die URL wird in einem ausgeblendeten HTML-Dialogfeld geladen,
                      alle Inline-Skript wird ausgeführt und das Dialogfeld wird geschlossen."

    Zusätzlich werde ich die dortige Anregung nutzen und das defer-Attribut:

    [Scripts in HTML documents - defer]
    http://www.w3.org/TR/html4/interact/scripts.html#adef-defer

    [About the Browser]
    http://msdn.microsoft.com/en-us/library/aa741313(VS.85).aspx#Adding_to_the_Standa

    zufügen, sodass der "user agent" weiss, dass das Script keinen Dokument Inhalt erzeugt, sodass der Agent weiter parsen und rendern kann.
    Auch, wenn die Beispiele "htm" benutzen, so geht auch daraus nicht hervor, welche erlaubten Extensions hier möglich sind.
    ________

    Als weiteres ist noch die Virtualisierung von HKLM/Software zu beachten, denn in Wirklichkeit landen die Registry-Werte in einem VirtualStore unterhalb von HKCU, da ich die Installer-Detection durch den "accent grave" in Instàller ausgetrickst habe. Würde es mit einem requireAdministrator-Manifest installiert, so würde es nicht virtualisiert und real in die HKLM-Registry geschrieben und ggf. Probleme wie unten aufgeführt, vermieden:

    [UAC References]
    http://msdn.microsoft.com/en-us/library/bb756883.aspx

    [Martin’s Blog » Der VirtualStore und seine Schattenseiten]
    http://blog.m-ri.de/index.php/2007/02/10/der-virtualstore-und-seine-schattenseiten/

    Leider weiss ich immernoch nicht, ob es hier eine "best practice" gibt, es gäbe ggf. auch ClipBoard-Berechtigungen zu berücksichtigen. Dennoch reicht mir jetzt der augenblickliche Stand erstmal, bis sich der nächste User bei mir meldet, dass es nicht bei seinem Browser funktioniert. Also betrachten wir das ganze hier also als abgeschlossen. Danke für die Mitstreiter.


    ciao Frank
    • Bearbeitet Frank Dzaebel Mittwoch, 15. April 2009 19:00 UAC-Thematik zugefügt
    • Als Antwort markiert Mathias Schiffer Sonntag, 19. April 2009 19:37
    Mittwoch, 15. April 2009 18:03
  • Hallo Kay,

    danke für Deine Hinweise, sogar mit Anrede!   (und Bild  ;-)

    Ich habe hier nicht nach ~weitergehender Unterstützung / technischen Support o.ä. gefragt.
    Das wäre sowieso bereits den Forenregeln zu entnehmen:

    [Forenregeln]
    http://social.msdn.microsoft.com/Forums/de-DE/internet_explorerde/thread/54f46602-2f66-48a6-be8d-0309c0114eeb

    Allgemein würde ich mich an Eurer Stelle aber eher im Stil an Eurer NG-Nettiquette in den technischen Entwicklernewsgroups orientieren.

    [Newsgroup - Netikette]
    http://support.microsoft.com/?scid=fh;DE;NGNetikette

    Zum Beispiel -> Zitat:  

        Ein kurzes! "Hallo" am Anfang und "Tschüß" am Ende kommen in den Newsgroups immer gut an.

    Es gibt übrigens Nachteile für die User, wenn man als Einzelperson mit allgemeinen Gruppen diskutiert.
    Allerdings genauso, wie es auch Vorteile für die Gruppen geben kann.
    Falls das ggf. nicht bekannt wäre, kann ich da gerne etwas dazu ausführen.
    ____


    Trotzdem möchte ich auch nochmal loben, dass es sowas hier überhaupt gibt, wo sich MSFT-ler die Zeit nehmen, User-Fragen zu beantworten.


    ciao Frank
    Mittwoch, 15. April 2009 19:26