I have developed a system in asp.net 4.0 and have MaintainScrollPositionOnPostBack set to True at the top of all the vb.aspx pages. This ensures that all users return to the correct section of a page on a post back.
This has been working perfectly for 8 years, however about 3 months ago a user contacted me to state that this no longer worked and when the pages were posting back they were returning to the top of the page and not where the user was working.
Since then I have had another 5 members of the staff notify me that they are also experiencing the same issue. As a result I have to get these users to use Internet Explorer which is functioning correctly. However this is not ideal as our system are developed using chrome and optimised for this browser.
What’s more, I have another 95 members of staff who have the same setup and version latest of Chrome (40.0.2214.94 m) where this is not an issue and the MaintainScrollPositionOnPostBack is still functioning correctly.
I have tried moving the MaintainScrollPositionOnPostBack setting to the WebConfig file and also using JavaScript to remember the user’s position but these fixes still don’t work on the 6 machines.
Could someone please point me in the right direction to fix the issue that I am experiencing.
Kind Regards
Wayne Cornish
Related
when go to paypal signin page I have page with broken layout ( seems problem in css ). Screenshot attached here https://snipboard.io/QGnx6K.jpg
Strange, but after this stage there is normal style webform but when go to the transfer money there are again css problem and button for transfer just don't work. It disturbs all opportunities
I tried to solve this by clearing cache and cookie browser, use another browser, install another browser but nothing helped. Also this problems reproduced on two my computers but when I tried third computer of my friend - all was fine and I could do transfer.
So how case could be fixed for my computer?
I've been experiencing the same thing. And it was all ok like a week or two ago. So I mean it's an issue on their end. Or we have some troubles with Paypal in our region (because the government promised to put some restrictions on Paypal very soon, maybe it has begun already?)
I have the Piczard SimpleImageUploader in a asp.net based management tool for a product catalog that seems to work just fine for most users, but for some users, the Edit popup will show, but then the image does not load. The logo and progress will just stay there and never move. Users are typically in IE 11 on a Windows 7 PC. We have tried in other browsers, but FF and Chrome seem to not allow the popup at all, probably due to the branching of Flash, which Piczard seems to need to run.
Could there be a setting in IE that is blocking the image from uploading? The tool worked just fine for the user a few months ago, but recently has not be cooperating. I was thinking it could be a Group Policy, but I have not been able to confirm that yet.
Any leads are appreciated.
Windows updates, IE Advanced settings Reset and a reboot fixed the problem this time. I do not know which setting or update fixed the issue at this point, just that it did. I had done the reset before but that alone was not enough to fix the problem.
I am working with an ASP.Net WebForms project that is using an UpdatePanel and in IE it is extremely slow to load the page, however in Chrome and FireFox this is not an issue at all.
I have seen and tried the answer here ASP.NET website very slow Internet Explorer 10
I have also tried the suggested answer here too https://www.devexpress.com/Support/Center/Question/Details/T268620
I also have the update condition set to conditional too as suggested here Update Panel working very slow
I should also note that I have a repeater on the page too.
When looking at what is sent and recevied using Fiddler I am getting this result
Bytes Sent: 1,888 (headers:1,331; body:557)
Bytes Received: 5,280 (headers:148; body:5,132)
When navigating to the page, the data is loaded and appears immediately, but the page is not responsive which is the actual issue.
I would apprecaite all help in order to resolve this issue and speed up the performance in IE to mach (as close as possible) that of Chrome and FF.
Edit -
Although this question has been asked, its been asked for different versions of VS.
I have resolved this now and have displayed the answer below
I found the answer, and did consider deleting the question, however the problem has now almost gone give or take its still a 2 second load, rather than a 15.62 on average.
In Visual Studio the system has a function that needs turning off and whoever stumbles across this question with the same issue this will hopefully fix it for you too.
http://www.poconosystems.com/software-development/how-to-disable-browser-link-in-visual-studio-2013/
Its a combination of the DevExpress link and the turning off the option in Visual Studio.
In our company, we have bought a web application that we are testing in the intranet zone. We are using IE 8.
Basically, on a particular page, there are a few buttons, and one of them populates a fairly big gridview.
Then as soon as I click on another button that causes a postback, I immediately get a 'web page navigation cancelled (DNS Error).
At first I thought it could be a problem with the URL being too long, but it's not the case.
Then, the vendor performed the same actions on his computer, and it worked correctly. Clearly, this is not a problem with the website itself, but probably a configuration with IE8.
Unfortunately, we cannot use or test with Firefox or IE9. We are stucked with IE8.
Any ideas?
Thank you!
Take a look at the answers on this thread, specifically the one by SpritX. Many reasons this could be happening and there are a few solutions in that discussion you can try.
I was working on some ASP.NET 2.0 pages when I noticed that some of the pages' back buttons were unavailable - greyed out. And clicking the drop down menu next to them showed clear results, as if I had come to this page fresh. I looked through the code trying to find something to specifically disable the back buttons (redirects, clever javascript), but found nothing. So I started picking apart the page and noticed that when two particularly large drop down lists (One had 38 thousand items!) were commented out that the back button would again be available. By 'Commented out' I mean I did not databind them in the code behind.
It seems that these pages used to work before I inherited this project. One of the things we did was upgrade the server from .NET 2.0 to .NET 3.5, although the code still targets the 2.0 framework. I doubt this is the culprit though.
This problem occurs in both IE 6 and IE 8 with all the latest updates. It occurs on Server 2003 RC2 with all the updates I could find and on Windows XP machines that the client has selectively updated but are all running IE 6.
My question is, has anyone ever heard of this, and if so, what causes it? Is it just an Internet Explorer bug?
Well, 38k options # 28 characters^1 gives one a page size of 1,064,000 characters for the options alone, nevermind the accompanying viewstate. Which, when I think about it is probably what is killing IE as your POST size has to be in the megabytes range.
Personally, rather than beat on the issue which you probably can't fix, I'd go for hitting it from the easier side of re-factoring the interface so users get a managable number of options. I really don't know how one could pick the correct one in 38k in the first place anyhow . . .
^1: <option value="x">y</option> is about as short an option as ASP.NET will generate and that is 28 characters. I'd bet we are looking at far more data than that. I pray this is an intranet app . . .