I have a simple asp.net page that contains a file upload element. When I'm in IE compatibility mode the page posts back to server fine. However, if I disable compatibility mode for some reason my code never reaches the server. Its failing somewhere in client code.
I know this is not a lot to go on but does anyone know off the top what I could look at to see what's happening?
Related
Since I installed Visual Studio 2010 from scratch about 2 months ago, it behaves slightly different when debugging JavaScript code being run in IE.
When I set a breakpoint, it opens a duplicate of the view with the term "[dynamic]" in the header and marks the breakpoint in there.
When a JavaScript error happens during execution, it does the same before it marks the line of code that threw the error.
This "dynamic" view is editable but edits have no effect - they are not saved to the file.
I find this behavior pretty uncomfortable. Everytime I notice an error in the code during debugging, I happen to fix it in the dynamic view. I hit save. VS does not complain. Next I refresh the page in IE, and - bang - the changes are lost, it loads the untouched old version again.
I haven't been able to find out how I can turn these views off. Before I re-installed Visual Studio it did not do that. It would only create "dynamic" views for script found in inline script tags in HTML files.
Try this
IE > Internet Options > Settings (under browsing history) > Check for new version of stored pages : Every time I visit the webpage.
This works for me in IE10.
Other option is to open Developer tools and select cache option Always Refresh from Server as show in the image below
Try hitting CTRL+F5 on the web page. That did the trick for me.
The problem was that I had opened other IE windows from a previous debugging session, so the dynamic javascript files were still cached.
Having developer tools open - F12 - should also cause the cache files for the page to be cleared on each refresh.
Changing the encoding of the JS file in question, from a Windows codepage to UTF-8, fixes this for me.
Narrowing it down, it appears that OEM Extended ASCII characters in the file (e.g. ALT-254 which I use for a bullet) trigger the problem with the Windows codepage files.
(Visual Studio 2013 Update 5, IE11)
For Google Chrome:
Open developer tools(F12)
Open Network Conditions Tool
Select Disable Cache
I had the same problem of not being able to hit a break point in new code. And breakpoints on old code in the same page will bring up the [dynamic] version. The edited page is not reloaded. This just started for me a week ago in both VS2012 and VS2013. Using refresh page and/or Ctl-F5 did not work for me. BUT, reading this thread pointed me to using F12 to open Developer tools. Leaving that window open, while hitting refresh does the trick. Thanks guys.
1) Run the page Without Debugging (Debug-->Start Without Debugging)
2) While the web page is open in Internet Explorer, press Ctrl-F5 so
that the IE cache is cleared. Ensure IE has the focus.
3) Close IE and re-run the page with Debugging (Debug-->Start
Debugging).
This fixed the issue for me.
Vague title, but it's tricky to word well in one question.
I have a site which uses a local database to store reviews, and in another table we store ratings of those reviews, so every time someone clicks a thumbs up / thumbs down icon next to a review a new entry is added to that table, much like the "is this review helpful?" feature you see on many sites.
This is done using a js function which triggered when either thumb is clicked on, which then calls an aspx page and in the C# behind we check if the user has already voted on that review, and if so to update the database appropriately (e.g. removing their vote if they have already voted in that direction).
This works well in Chrome and IE on the laptop I am working on. I have tried the latest IE 10 standards as well as IE 8 standards as the latter is what most people will be seeing the site with, but it partly doesn't work on someone else's computer with the same browser version installed and same standards set. I had this user log in to the site on my machine to see if it was a user account issue, but it worked fine for them on my machine.
I have tried loading the site in InPrivate browsing windows to prevent any caching affecting the issue.
It works for them to submit a vote, either up or down, and they can change their vote from up to down, and the database is updated correctly. If they try to remove their vote however, it simply doesn't work.
It's not a user issue, as it works fine for both of us on my machine, and for neither of us on their machine, so I figure it some browser setting of some kind.
Summary:
- Works in Chrome
- Works fully in IE on one computer
- Doesn't work fully in same IE on another computer
Any pointers?
Caching issue. This explains why the database was updated the first time, but each time after it wouldn't work properly. Using the code below to prevent caching:
// Stop Caching in IE
Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);
// Stop Caching in Firefox
Response.Cache.SetNoStore();
I am using .NET 4 and trying to use the desktop authentication for the StackApps site via the web-browser control (WPF and/or WinForms) to develop a NNTP Bridge for accessing StackOverflow (https://stackapps.com/questions/4215/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
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:
Create a WinForms-Project
Add the "WebBrowser" control to the dialog
Double-Click on the Form1
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");
}
Start the application
Login by pressing the "login with Stack Exchange" account symbol
A new page gets loaded; it is displayed correctly, but you cannot enter your login name; the window hangs...
The same happens, if I use WPF-App and the WPF-WebBrowser-Control... it seems that it is stuck in an endless-loop in JavaScript...
Any hint on how to solve ths problem?
Or is it possible to debug the JavaScript in the WebBrowser-Control???
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.
Unfortunately, I'm not a JavaScript developer, so I only could try to explain you how to debug a JavaScript that executes in the WebBrowser control.
This approach is for the Microsoft Visual Studio, I don't know if Delphi can provide similar functionality.
Enable Script Debugging (both Internet Explorer and Other) in Internet Explorer settings.
Disable Friendly HTTP messages in Internet Explorer settings.
Enable Display a notification about every script error in Internet Explorer settings.
From Visual Studio, start your WebBrowser hosting application without debugging (i. e., Ctrl + F5).
In Visual Studio, go to Debug → Attach to Process… and select your application in the list.
Hit the Select… button to the right of Attach to: field and choose Script code.
Hit the Attach button. Visual Studio starts the script debugger.
In your application, navigate to the deadlocking page by pressing the Login with Stack Exchange account symbol.
Go to Visual Studio and press the Pause button on the debugging toolbar.
Now you can look into your script code and investigate the code itself, the call stack, the variable values and so on. You can set breakpoints too. Perhaps you can then find the place where the script hangs. As I said before, I'm not a web developer and cannot help you with this…
Update:
I guess I can propose you a working solution.
My investigation shows that the WebBrowser hangs when it renders the content in the IE7 mode (what is the default mode even if you have IE10 in your system). You should force it to switch into IE9 mode. In IE9 mode, the page renders well and does not cause the script to stuck in an endless loop.
You can switch your WebBrowser to the IE9 mode using one of the following methods:
Define the global browser emulation mode for your application in Windows registry.
For 32 bit OS, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION.
For 64 bit OS, use HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION.
In this node, create a new DWORD parameter called YourApplicationExeName.exe with a value 9000 (0x2710). You can create another entries for your *.vshost.exe executables, if you want this to work in Visual Studio debug mode.
Manipulate the source for the WebBrowser to switch it in the IE9 mode.
This will be more complicated. You need to alter the <head> tag of the html document adding a new <meta> tag preferably as a first element: <meta http-equiv="X-UA-Compatible" content="IE=9"/>.
This will cause the WebBrowser to switch its mode on document rendering. Since you can't change the compatibility mode after the document is rendered, you could use a proxy as a source for your WebBrowser, so this proxy will add the header.
I`ve successfully tested this with the 1st approach, and the second one should work too.
Hope that helps!
Project + Properties, Debug tab, tick the "Enable native code debugging" option. Ensure that you've got the Microsoft Symbol server enabled (Tools + Options, Debugging, Symbols), I know you do :)
You can now use Debug + Break All and see what's going on inside the browser. Do so repeatedly to get the lay of the land. You'll see that Javascript is executing (jscript8.dll) and constantly forcing the layout engine to recalculate layout, never getting the job done.
Browsers in general are vulnerable to Javascript that's stuck in an endless loop. A regular browser tends to put up a dialog after several dozen seconds to allow the user to abort the JS, but WebBrowser doesn't have that feature. Nor does it have the dev tools so debugging the JS isn't going to be a great joy either. This is going to be difficult to get fixed.
You might consider using the OAuth 2.0 api instead. Notes on usage are on this web page. Exactly how to integrate that with WebBrowser is a bit murky to me, I don't have a key to test this. Find help for this at the Stackapps site. You are probably not the first SE api user that ran into this problem.
So I've been trying to figure out why the application pool keeps crashing every now and then, and I've pinpointed the page that is cau seems to be causing the issue.
When I open the site in the browser, and visit the Shipping cart page (after adding stuff to the cart), the entire browser becomes unresponsive, and I open Task Manager, and see that IE (browser) is using 99% CPU, so I right-click > Create DUMP > Try to read DUMP but WinDBG does not seem to like DMP files; won't read them.
So I move on, and try to figure it out without the dump files. I fire up Visual Studio, open the site in question, and then follow the same process (add stuff to cart, then visit cart page). And to my surprise, everything is OK.
Not sure what to do now. Any suggestions? How would you determine the cause of the hanging, when everything runs perfectly, locally - and when everything used to run perfectly online, but no longer runs fine online?
If the browser becomes unresponsive and eats 99% CPU, that's a client side problem; it most likely doesn't have anything to do with IIS or your server side code.
Could it be that you have some javascript in your page is buggy and goes into a busy loop? I think it's worth a shot to test this (use either IE's developer tools (F12), Visual Studio's javascript debugging functionality, or FireFox in combination with FireBug).
Edit
It strikes me as odd that your AppPool crashes, and in doing so, causes the web browser to turn non-responsive. With non-responsive, do you really mean that the browser itself stops working (i.e. navigating a page back or going to another url such as google.com is impossible?)
Anyway, if you think the problems occur on the server-side, you could try the following things (in order of increasing effort):
After an AppPool crash, check the windows event log (run 'eventvwr' from a command prompt) and see what information that gives you.
View the IIS log (you might have to turn it on first), see if it contains any weird request patterns, such as your page getting hammered)
Run your website from IIS, but attach a debugger from Visual Studio (under Tools, Attach to process - include only managed code) to the IIS worker process (usually w3wp.exe). If your page throws an exception, VS should be able to catch it.
Add more tracing to your page, the Global.asax's Application_Error seems like a particularly good candidate.
We have a problem with many of our website written C# ASP.NET.
The problem is that often a C# page will never fully load from the server.
The page content itself load fine but Images but more annoying Scripts (Javascript) seam to hang and never come down and depending on the content it might lock up the page on Ajax Postback.
This problem is not limited to a single server as it happens on development machines as well as pre production and production servers.
The development machine are just using the inbuilt VS IIS Instance.
All pages that have this problem use ASP.NET Update Panels with varying versions of AJAX Toolkit.
Thanks
One of the possible reasons is that your postbacks are being triggered on some events which are either being fired continuously. Another possible cause is that the page life cycle is not getting completed (e.g. infinite loop). If you can post some code, you would get precise answers.
Thanks,
Vamyip
Try using asp.net trace to see which page event is taking longer. Also try using fiddler from client side to see the real traffic and error codes. If you share the fiddler logs I may be able to tell more about what's happening.
You can check the time used by all the resourced that are loaded on the page using Firefox and firebug add-on
Anyway the updatepanel doesn't work very well with heavy pages : it posts the whole page to the server and get the whole rendered HTML even if you need refresh a small portion of the page.
if you can you should replace the updatepanel with async Jquery call to the get the the response as JSON and then populate the page as you wish or try to use anothe approach similar to the update panel.
have a look at:
http://www.codeproject.com/KB/aspnet/partialRendering.aspx