code it

Martins Tech Blog

InvalidOperationException in WebBrowserTask.Show

In Windows Phone 7 hat man mit Hilfe der Launcher und Chooser die Möglichkeit, auf im System integrierte Funktionen zuzugreifen - sei es nun die Kamera, der Emailclient oder wie in meinem Fall der Browser. Meine Anwendung hat mehrere Buttons über die zu unterschiedlichen Webseiten weiternavigiert werden kann - hauptsächlich als weiterführende Information im Impressum.

Dafür hab ich abstrakt gesehen folgende zentrale Methode:

public static void OpenInWebBrowser(string url)
{
    var openBrowserTask = new WebBrowserTask { Uri = new Uri(url) };
    openBrowserTask.Show();
}

Diese Methode wird direkt in dem Command aufgerufen, das an dem Button hängt - alles kein Hexenwerk. Was mich nun wunderte: Gelegentlich bekam ich Error-Reports mit diesem Inhalt:

Navigation is not allowed when the task is not in the foreground. Error: -2147220990

Da stellte sich mir folgende Frage: Wie kann jemand den Button klicken, wenn die Anwendung nicht im Vordergrund ist?

Die Lösung ist ganz einfach: Der Benutzer hat kurz nacheinander auf den Button geklickt - sei es nun weil er so aufgeregt war, eine schöne Webseite zu sehen oder weil er gerade unterwegs auf einer holprigen Straße war - die Möglichkeiten sind da ja sehr vielfältig. Das ist möglich, weil der Launcher eine Weile braucht, um den Browser in den Vordergrund zu holen. Der Nutzer kann also dafür sorgen, dass der Click-Event zweimal ausgelöst wird - der zweite Event wird aber erst dann verarbeitet, wenn der erste WebBrowserTask den Browser geöffnet hat und damit die eigentliche Anwendung nicht mehr im Vordergrund ist. Und dann kommt es zu dieser Exception.

Wie geht man nun damit um? Es gibt mehrere Ansätze. Zum einen kann man natürlich mit Try-Catch-Blöcken arbeiten und genau diesen Exception-Typ abfangen. Da diese Exception bei dieser Methode bisher in der MSDN nicht dokumentiert ist, ist es etwas schwierig hier von allein auf die Idee zu kommen, diesen speziellen Typ abzufangen, aber nachher weiß man es immer besser. Zusätzlich könnte man noch den Click-Handler abhängen bzw. den Button oder das Command deaktivieren. 

Ich bin nicht der einzige, dem dieses Problem untergekommen ist - und Niko hat einen sehr ausführlichen Blogpost zum Thema geschrieben, der auch alle hier genannten Lösungsmöglichkeiten aufführt.

Request Validation an eigene Bedürfnisse anpassen

Die Validierung der an die Webanwendung übertragenen Daten spielt eine zentrale Rolle, ist sie doch der Garant dafür, dass kein schadhafter Code eingeschleust werden kann und verhindert Cross Site Scripting (XSS). Und wer hat nicht schon einmal den YOSD gesehen, der erscheint, wenn ein Wert eingegeben wird, der auch nur im entferntesten wie HTML aussieht.

Was hier passiert ist klar. Die Request Validation von ASP.NET hat in den Eingabewerten einen Eintrag gefunden, den sie als potenziell unsicher erkannt hat und schützt nun die Anwendung indem eine HttpRequestValidationException geworfen wird. Was für Entwickler an der Request Validierung störend ist, ist, dass sie an einer Stelle vorgenommen wird, an der nicht so richtig gut eingegriffen werden kann - sie geschieht vor der BeginRequest-Phase des Http Requests. In meinem Post zum Attribut AllowHtml habe ich schon gezeigt, wie man mit Hilfe des AllowHtmlAttribute an Eigenschaften des Models die Request Validierung für einzelne Feldwerte deaktivieren kann. Aber ASP.NET bietet noch eine weitere Möglichkeit, in die Validierung einzugreifen: eine eigene Implementierung der Request Validation. Mehr...