Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

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...

share|improve this question

This question has an open bounty worth +50 reputation from GolezTrol ending in 5 days.

This question has not received enough attention.

I hope to get either a work-around for this issue, or draw attention to the issue from the StackApp developers so this issue will be fixed in the login form. If you want to earn more, make sure to answer this question's duplicate on StackOverflow as well.

    
Maybe refactor this as a .net question on Stack Overflow? –  Brock Adams Jul 26 '13 at 23:15
    
I asked the question on stackoverflow.com/questions/17895156/net-4-webbrowser-hangs/… ...it seems that it is a Problem with the Java script... so it is a problem with the StackApp-Authentication... where is the right place to ask for Support for Desktop-Authentication? –  Jochen Kalmbach Jul 27 '13 at 17:24
    
This is the right spot for the SA authentication part, but I had thought it might be more of a .net issue. –  Brock Adams Jul 27 '13 at 19:02
    
Is anyone able to reproduce this issue? –  Jochen Kalmbach Jul 28 '13 at 16:53
    
It may take a while. Of the few that frequent this site, even fewer are .net users. (I avoid MS products like the plague). –  Brock Adams Jul 28 '13 at 17:44
    
The problem is not primarily .net; the main problem is embbeded IE with the specific JavaScript in the web page... this also might happen for non-.BET apps (like MFC).... but you are right: The problem is Windows with embedded IE browser and the particulary JavaScript in the page... –  Jochen Kalmbach Jul 28 '13 at 18:41
    
I am also seeing this on Windows 8.1 with Internet Explorer 11. I am trying to call the StackExchange API from PowerShell, and it is hanging at the "Authorizing Application" screen. –  Trevor Sullivan Dec 24 '13 at 2:34
    
I tried to call the StackExchange API using a TWebBrowser control in Delphi (Windows 8.1) and it also hangs with a high CPU usage. I tried to add a FEATURE_BROWSER_EMULATION setting for IE for my application, but that seems to help nothing. I don't have much rep here, so my bounty is small. :) –  GolezTrol yesterday

1 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 62 bit Windows, you might also need to add it to the second key, although I'm 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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .