6
votes

System.Windows.Forms.WebBrowser semble être désactivé JavaScript?

J'ai un problème avec System.Windows.Forms.WebBrowser

sur chaque machine, à l'exception d'une, cela fonctionne bien, mais sur cette machine JavaScript semble pour être désactivée sur la page que le contrôle tente de rendre.

J'ai traversé tous les réglages du système que je peux trouver de le relier et lui dire d'autoriser JavaScript, mais pas de dés. Je ne trouve aucune information nulle part sur un problème similaire et je suis complètement excentré.

À peu près, toute suggestion est la bienvenue à ce stade (même si cela implique de déplacer cette question à SuperUserer)

Pour me frustrer davantage, la même page affiche bien avec JavaScript qui fonctionne lorsque je le navigue dans Internet Explorer - Ce numéro ne manifeste que lorsqu'il est exécuté à partir de mon application.

EDIT: Système est Windows Vista avec les derniers packs de service, etc. installés, et la page est visualisée tandis que connecté à un VPN


8 commentaires

Je supprimerais vos tags (C #, Winforms) et ajouter un contrôle WebBrowser et Internet-Explorer. Le WebBrowser WinForms est juste une enveloppe autour du composant COM. Cela pourrait obtenir de meilleurs yeux sur la question.


J'ai changé les tags, mais j'ai gardé C # parce que c'est un peu pertinent - le bogue pourrait toujours mentir théoriquement avec l'emballage.


Les scripts sont définitivement pris en charge. En fait, la classe a une propriété ObjectForCripting. Ajouter un


@Sheng c'est le problème que je suis voir pour une raison quelconque, le script est éteint


Avez-vous vérifié sur l'ordinateur où il y a un problème, dans quelle zone l'URL de destination appartient? JavaScript est-il activé dans la zone? Pouvez-vous ouvrir la même URL sur l'ordinateur directement dans IE et JavaScript sont activés? Si vous chargez des javascripts d'une autre URL à partir d'une autre zone, vérifiez également ces zones.


YeP, JavaScript est activé dans toutes les zones - Affichage de la même page de Internet Explorer autonome fonctionne bien, ce n'est que lorsqu'il est exécuté dans le contexte de mon application que cela se produit.


Si vous voyez le texte dans


Pas de sécurité personnalisée, les scripts activés partout où je peux voir. C'est pourquoi je suis tellement confus.


3 Réponses :


3
votes

Si cet ordinateur est dans un domaine, l'administrateur pourrait avoir défini une stratégie de groupe très restrictive qui interdit d'exécuter JavaScript dans des cadres d'explorateur embarqués. Il y a une assez bonne raison pour que (cadre intégré soit sensiblement plus vulnérable que IExplorer.exe) et il n'y a rien que vous puissiez vraiment faire à ce sujet.


6 commentaires

S'il y a une restriction de politique, la même URL ne peut pas être affichée dans Internet Explorer, mais lee a écrit dans l'un des commentaires "Affichage de la même page dans Internet Explorer autonome fonctionne bien"


Mal - veuillez lire attentivement ce que j'ai écrit ci-dessus. Les cadres d'explorateur embarqués sont des menaces de sécurité connues et peuvent obtenir un traitement séparé si CORPNET Admin a l'impression de le faire. Le cadre d'explorateur incorporé n'est pas identique à celui de l'EXE.


Je l'ai regardé, et il ne semble pas y avoir de politiques de groupe qui causerait ceci :( Je pense que cela vaut la peine de réviser si c'était au cas où ils manquaient quelque chose


J'espère que vous avez aimé la série Twilight Zone :-) 2 Pages MSDN Parlez de commandes de fonctionnalités pouvant être appliquées au moins vers des fichiers binaires individuels et apparemment à des commandes individuelles WebBrowser. La liste est la même que celle-ci s'appliquerait en général si elle était dans la régiste, mais elles ne sont pas dans le registre sont dans des endroits que MSDN n'a pas l'impression de mentionner - ils n'adaptent pas l'API pour une application par contrôle non plus: msdn.microsoft.com/en-us/library/aa970906.aspx


On et si vous avez du temps à brûler, vous pouvez essayer de jouer avec des invoquescript et une objectoire pour essayer de causer une exception volontairement - bonne tonnerre peut dire qui l'a fait, surtout quand elle est en dehors de .NET. La mise en garde est que vous pourriez avoir besoin au moins de débogage indigène dans VS et peut-être même WINDBG de voir des exceptions et des hésultats qui sont mangés.


Toujours pas résolu, mais cette réponse et les commentaires sont les plus utiles (et je pense que mon meilleur tir à la trier) - merci



0
votes

Avez-vous vérifié le contenu HTML envoyé sur le contrôle de votre navigateur?


0 commentaires

2
votes

Assurez-vous de vérifier que la propriété ScripterSuppressiond est définie sur False.

J'ai eu des problèmes sur lesquels le script n'avait pas d'autorisations à exécuter et que le contrôle réduisait les fenêtres contextuelles, de sorte que cela ne m'a pas dit qu'il y avait une erreur sur la page.


0 commentaires