We have an ASP.net 3.5 WebForms application using VB.Net which has been running for many years. In this application there is a gridview select button that does not postback for some clients. This problem started occurring for some of our client when we moved the web application to IIS 7 on Windows Server 2008R2 from Windows Server 2003.
The select button is defined in the gridview with asp:CommandField ShowSelectButton="True"
which generates code as follows (copied from HTML source):
a href="javascript:__doPostBack('ctl00$bodyContentPlaceHolder$GridView1','Select$0')" style="color:#333333;">Select</a>
For some Win XP, Win 7 users who use IE (various releases), it does not postback when the user clicks the generated button. All users have been checked to ensure that javascript is enabled. For other Win XP, Win 7 users who use IE and other browsers, it works fine.
Much googling has turned up information about Javascript postback problems, but nothing seems to fit.
Other information: The whole gridview row is enabled for postback with this code in the GridView Rowdatabound event:
e.Row.Attributes.Add("onClick", "javascript:__doPostBack('" + Replace(GridView1.ClientID, "_", "$") + "','Select$" + e.Row.RowIndex.ToString + "')")
which generates this HTML:
<tr align="center" valign="top" onClick="javascript:__doPostBack('ctl00$bodyContentPlaceHolder$GridView1','Select$0')"
Note that the Javascript reads identically to the javascript which does not work, except that clicking elsewhere in the row DOES work for all users. This brings me to three possible issues:
Is there something about the SELECT button being in a link tag that makes it fail for some users?
Is there a user setting that might be different?
Is it something the Internet Provider is blocking?
1.Is there something about the SELECT button being in a link tag that makes it fail for some users?
It seems unlikely, since the page should be rendered the same way for all users (unless you're doing client detection that you didn't disclose).
2.Is there a user setting that might be different?
Maybe. Things that I would look for include:
Check the Compatibility View Settings to find different settings (try this during development, as well).
Check whether users have add-ons that could interfere (run iexplore.exe -extoff to run IE without add-ons)
Force IE to ignore the cached pages (I find the easiest way to do this with IE7 and up is to press F12 for the Developer bar, and choosing "Always Refresh from Server" on the Cache menu).
3.Is it something the Internet Provider is blocking?
I doubt this very strongly.
Related
I made a lot of research on this topic but none of the found solutions helped me.
So, let's start: I have a VB ASP.NET WEB Application.
The problem is the users can see the source code of the aspx files in the browser (IE) when the Display intranet sites in Compatibility View is unchecked.
I tried all of the methods, settings compatibility from IIS, web.config or even from the meta tags from <head>.
I discovered that also with the checkbox unchecked if I use Enterprise Mode the browser displays the page ok.
I tried then to find a solution to force the Enterprise Mode from code but I didn't find anything without changing registry keys. Changing registry keys can also be done to the above checkbox.
If I go in the DOM Explorere in IE and I try editing the source, anything I delete from there, the page is displayed ok.
How can I force the Enterprise Mode, or the Compatility View Mode from code? or is there another solution for me to solve this problem?
In my opinion you need to check the caching of the application if you say that if you modify something in DOM the page appears.
I created a new VS 2013 project and viewed the default.aspx page with the Firefox browser. When I check the net calls it has made, I see it making constant calls to:
http://localhost:50682/6a663a78019845d5ade4a328cad09cc2/arterySignalR/poll?transport=longPolling&connectionToken=AQAAANCMnd8BFdERjHoAwE%2FCl%2BsBAAAAOBmDwPWa2ky2MAZXFHBMVAAAAAACAAAAAAAQZgAAAAEAACAAAADSADQXBVKiKczflJ0OzUjOLduFTJE4zd%2FLHWGpDfXnuAAAAAAOgAAAAAIAACAAAACyEX81VwilygfphPoEKCYQ6ZwrkzExoKfZzEMkqBKqqzAAAADG%2BDJbrEFOfsNm9OKhqacnGseQvrwy5kmyZnI5YJiZbjYFgzMELXHfwA7Sxjj4osJAAAAAvQvoG4N0nn8eB9FRaJaZyqaUDF%2F9ypvGN%2B%2BVefnx8U1Fq6P9HXO9vEC%2BfA2s8R4jik58rD4IcFMjM4P8l5kv6g%3D%3D&messageId=d-F1180A0E-W%2C0%7Cl%2C4%7Cm%2C0&requestUrl=http%3A%2F%2Flocalhost%3A50656%2Fdefaulttest&browserName=Firefox&tid=4&_=1384207744328
Why is it doing that?
How do I stop those calls?
I see an infinite number of calls made to the above URL every 6 seconds.
Please help me understand this and fix this.
This is working as intended. Artery aka BrowserLink is a real-time connection from Visual Studio to all browsers running your code. It essentially allows Visual Studio to interact with every browser.
For instance if you have IE, Opera, Chrome and Firefox all running your code and you're trying to ensure cross browser correctness; instead of going to each browser and hitting f5 to refresh you can just click the browser link refresh button which will auto-refresh all of the pages for you.
Not everyone wants or needs to have this functionality so if you do want to disable it, as Gustavo Armenta said you can disable it by following the steps here: How can I disable __vwd/js/artery in VS.NET 2013?
I would recommend you to read this post first Browser Link feature in Visual Studio Preview 2013 to understand about this new feature that comes in with VS 2013.
And then to disable this, simply uncheck the "Enable browser link" option.
You can hide the polling requests from the Chrome developer tools Network tab so that the requests you are actually interested in become visible. You can hide the polling requests by adding a negative filter:
On the Network tab, click the filter button to open the filter options
Enter "-poll" without the quotes to hide the polling requests.
Example:
Had issues with that on site running with KnockoutJS framework. Pages were freezing for 10 seconds until "BrowserLink" external scripts were loading (using Chrome browser).
Issue solved by disabling "Browser link" feature in VS 2013
Steps How to disable "Browser link" (thanks to Gustavo Armenta for leaving comment with link in question)
I've written an ASP.net site that requires the use of a 3rd party ActiveX control.
Everything works as expected however when a new user visits the page for the first time they do not get a firts time prompt to install the activeX control. (the yellow bar in IE).
Where do i begin troubleshooting ?
In the Internet Properties on a users computer, there are various security settings regarding ActiveX controls, and if the browser will automatically download and run, prompt to download and run, or just not do anything with them.
These settings can be adjusted for both Internet and Local Intranet, so it might be that you will need to change the level of security?
Figured it out,
For some reason referencing the OCX in the root of the application does not call the first time install.
None of the following work in the HTML markup
<OBJECT ID="xxx" classid="xxx" CODEBASE="/axcontrol.ocx"></OBJECT>
<OBJECT ID="xxx" classid="xxx" CODEBASE="~/axcontrol.ocx"></OBJECT>
<OBJECT ID="xxx" classid="xxx" CODEBASE="../axcontrol.ocx"></OBJECT>
But if i place the ocx in the same folder as the host ASPX page and set the CODEBASE="axcontrol.ocx" it works fine
I have a very unusual problem that actually took me quite some time to even locate the root cause. I have an ASP.Net 3.5 web application running on Windows Server 2003. I was getting reports from users that said every so often the application would refresh on its own, without user interaction. This was unusual as I have not coded any client side refreshes. After much troubleshooting I narrowed this down to an issue with Internet Explorer (both 7 & 8). FF, Chrome, and Opera do not exhibit this behavior.
Basically, this only happens the first time a user visits the site on a new instance of IE (either a new window or new tab). If the user goes to any page within the site, and then does not interact with the site again, after 6 minutes the browser refreshes! After that refresh, as long as it is the same instance of IE, no matter what page on the site you visit, and no matter how long you let it sit, you never see the refresh again. This has really baffled me, and has become a major problem as this app has data entry forms that take longer than 6 minutes to complete. Unfortunately, if the user gets caught by this refresh bug, anything they entered is lost because of the post.
I need help!! Any advice or options to try would be greatly appreciated. Thanks!
(no, I cannot require them to use a better browser as this is a corporate environment with restrictions set to use IE for non-technical users)
It's a stretch, but maybe you have a 3rd party component that's adding a meta refresh tag only for IE (see http://www.w3schools.com/tags/att_meta_http_equiv.asp (refresh value)). Or maybe there is client-side code generated somewhere only in the case of IE that puts a location.reload() or location.href = someLocation a client-side script block in your markup.
Have you compared the HTML markup in IE and and FireFox? Are they the same? That's where I would start. If they end up being the same, look at script references and search for location.reload() or location.href.
And actually maybe before that, run IE without Add Ons enabled and see if it refreshes. To run without addons, do this at the command line, "C:\Program Files\Internet Explorer\iexplore.exe" -extoff
This one has been a stumper for me. Its very easy to duplicate though a rather obscure issue. It came about as I was doing some javascript work on a web page yet also make use of the validation controls that ASP.NET provides.
Some specifics up front: using a Vista-based development machine with the 3.5 framework and IIS 7. I also have a QA machine that is running windows server 2003, also with the 3.5 framework but running IIS 6.
Take a page with a simple TextBox, Validation Control, and button to submit them. For example:
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server" ErrorMessage="Text is Required" ControlToValidate="TextBox1"></asp:RequiredFieldValidator>
<asp:Button ID="btnSubmit" runat="server" Text="Submit" />
Simple ASP.NET validation control code here ... The idea here is that client-side validation code is generated for the required field and a postback is not done unless the text box has a field. If the browser does not support client-side scripting, then ASP.NET will catch it on the server side using the Page.IsValid property.
When I run this from my Vista-based development machine, the client-side scripting code is generated for both IE and Firefox and works just fine.
When I run from the win2003-based QA machine, client side code for the validator controls is also generated for both browsers. The validation code for IE works fine ... but does Not work for Firefox. When the submit button is pressed (with an empty text box), the client-side code appears to be ignored and a postback performed. Now the validation error is caught server side - but I want to know why its not working client side in the first place.
The interesting quirk here is that if I take page source views under Firefox from the Development machine (the one that works) and the QA machine (the one that doesn't) and compare them - the client side validation code is dramatically different.
Ideas on what to change to get the client side validation code to work in Firefox with the QA machine?
UPDATE: Had a few comments asking to see the generated source. I've saved the Dev and QA source as .htm files and zipped them up. You can get them at http://www.optsolutions.com/testvalidation.zip
Check your web.config for xhtmlconformance and make sure it is not set to legacy.
http://aspadvice.com/blogs/rbirkby/archive/2006/11/01/Client_2D00_side-validation-in-Firefox.aspx
I am having the same issue with a similar setup. Differences in the browserCaps settings is the most promising possibility I have come across so far.
http://msdn.microsoft.com/en-us/library/sk9az15a(VS.80).aspx