Desktop login URL: WebBrowser hangs (.NET) - JavaScript endless-loop

Question

I am using .NET 4 and trying to use the desktop authentication via the web-browser control (WPF and/or WinForms; StackApp NNTP bridge for accessing StackExchange forums (like StackOverflow)). It seems that the login cannot be done, because the web browser hangs up, after the page from "StackExchange Login" is displayed. I use the following URL: https://stackexchange.com/oauth/dialog?client_id=1736&scope=no_expiry&redirect_uri=https://stackexchange.com/oauth/login_success

Edit: Looking at the callstack of the hang, it seems that it hangs in an endlessloop in JavaScript of the page. So the desktop-authetntication is not usable for Windows applications!

It works in the normal IE browser, but not in a WinForms or WPF window... Does anyone know what the problem is?

It is simple to repoduce:

1. Create a WinForms-Project
2. Add the "WebBrowser" control to the dialog
3. Double-Click on the Form1

4. Add the following code

   private void Form1_Load(object sender, EventArgs e)
   {
     webBrowser1.Navigate("https://stackexchange.com/oauth/dialog?client_id=1736&scope=no_expiry&redirect_uri=https://stackexchange.com/oauth/login_success");
   }
   

5. Start the application

6. Login by pressing the "login with Stack Exchange" account symbol
7. A new page gets loaded; it is displayed correctly, but you cannot enter your login name; the window hans...

Has anyone used the desktop-URL inside a desktop-application under Windows? It seems that I am the first one.... and the page has some JavaScript bugs...

Answer 1

Fixing WebBrowser Control

I also had the issue of the WebBrowser control handing when trying to login.

Although requesting a token in IE (11) works, I found that IE itself also hangs when I put it in IE 7 emulation mode. This suggested to me that my previous attempt to make the WebBrowser control use a newer version had failed.

I found this article, Web Browser Control Specifying the IE Version, which suggests that for 32 bit applications in 64 bit mode, you need to set a different registry value.

So now, I've added two values in the registry:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

and

HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

In both of them, I added a DWORD value named 'MyExecutable.exe' (where MyExecutable is the actual name of my executable). The value for each of them is 9000 which will work for IE9 and above. Watch out when using RegEdit to test this, it will default to hexadecimal instead of decimal. Also, make sure it is a DWORD value, not any other type.

This seems to do the trick. I can now run the application, go through the login process, and eventually I am redirected to the url specified by me, which I can then capture using the OnNavigate event of the webbrowser control.

Remaining issue

It doesn't really work perfectly. The first time I was redirected to some OpenID page as well, but at least the form didn't hang. With subsequent attempts, apparently the login (which succeeded before) is remembered and I get the message "Navigation to the webpage was cancelled" with a link to refresh the page. When I click that link, I am immediately redirected to the redirect_url I specified when requesting the login form. At least that part works, and I get an actual access_token and an expiry time, so for now I'm happy.

Update: After some testing, it turned out that the previous login was remembered. That causes the request uri to direct to the redirect_uri immediately. I used the OnBeforeNavigate event to detect this, but it isn't fired in this case. I now linked the NavigateComplete2 event, and that one is triggered in this scenario.

Fix for .NET?

I think for .NET the solution should be the same: add the executable (and MyExecutabl.vshost.exe as well, for debugging purposes in Visual Studio) to the first key. If it's a 32 bit executable running on 64 bit Windows, you might also need to add it to the second key, although I'm not sure if that rule applies to .NET as well. I don't do C# on a daily basis, and I'm trying to get it to work in Delphi first, but if I find time to test this in C# I will post the update here.

In the end, it would be nice if the actual issue would be solved, and the JavaScript would work in IE7 mode as well, but at least this seems to be a proper work-around.