I have build an asp.net web site with 3 pages.
One of the pages has an update panel. It takes the server few seconds to update this panel.
When the client asks the server to update this panel, and tries to navigate to another page in my site at the same time - a problem occurs on FF only: the client cannot submit request to navigate to another page. Its request seems to be stuck (via firebug).
I googled and found that when a ajax request is invoked, the update panel is blocked and no other request to the server can be handeled. Is that so? Does someone can shed some light about the problem and how to solve it?
Thanks in advance.
This may be to do be firefox not being able to resolve the __doPostBack call correctly? When __doPostBack is called, if the script is unsuccessful in making the ajax call it falls back to a full post back of the client. Try looking into differencing of how firefox might handle this script call, not sure of the exact solution, but hope it helps.
Related
I have just started a MVC project and I faced with a very strange behavior.
When I run it it displays me some empty Home/Index
But when I go to firebug I see tens of very strange and endless requests, like this one:
GET http:// localhost :58567/3a5679dd22ba46d1993...%00101+Firefox%2F33.0&tid=7&_=1417193472430
And such the requests go one after another one and don't stop, although I don't trigger any action.
I don't understand where they come from. My app does not send any request and previously I've never faced with such the behavior. In my previous experience firebug showed me only the requests I made.
Please advise.
These requests come from the "Browser Link" feature in Visual Studio, they're not something you'll have manually added. There's more detail on the feature at http://www.asp.net/visual-studio/overview/2013/using-browser-link , including how to disable it if you don't need it.
I have a successfully running signalr project where the work is done from an html page. I have taken the exact same html and pasted it into a .aspx page (with no master).
The signalr connection fails from the .aspx page giving error: Error during negotiation request
Has anyone any idea why this is. The code is exactly the same in the html and the .aspx page.
Have not included code here as it is working from the html page but if someone needs it please just ask.
Gave up late last night, woke up and first thing I thought of was so blindingly obvious but will post here anyway in case it helps someone else - by moving to a .aspx page, a postback occurs when the input button is clicked (obviously)!. Anyway so by just adding return false; to the javascript button onclick function resolved the issue and am now able to connect to signalr.
I am encountering a strange issue which is only affecting several users from an over 7000 user-base. Having searched the web for several hours to no avail, I'm hoping someone here can help!
I have an ASP.NET 2.0 website and when certain users try to access the home page (Default.aspx) they receive a white screen with no content loaded. This issue is occurring both in production environment and if I run the solution against a copy of production data. So I am able to replicate the exact same issue when I pseudo the problematic users.
When debugging the application in VS2005 and set a breakpoint in the code behind in the Default.aspx, the breakpoints are fired/hit so I know the request is working. The problem seems to be once the server has finished serving the request, the response back to the client/browser is empty.
Here's another strange thing I've noticed. If I alter the HTML in Default.aspx by adding a new white line or whitespace, the page will load fine for the same set of users. I thought I had resolved the issue with this fix but unfortunately the white screen issue just manifests itself once again.
Within Default.aspx, there's some AJAX requests using jQuery .load function but this can't be the issue because this functionality exists for every user of the site. The only variable is the amount of content returned within this request can vary depending on the user. But why would it resolve itself when I put a whitespace or whiteline in the page and then manifest itself hours later?
Another thing to note is it's only Default.aspx that is encountering this issue. If I browse to another page by typing in a page in the address bar, the page is served OK.
Hope someone can point me in the right direction on how I can debug or even resolve the issue.
It sounds like your ajax is the cause but without seeing some code, it's difficult to know why.
It could be a timeout, or an error that is preventing the ajax from completing it's function.
You need to use a tool like Charles or Fiddler to debug what is happening whilst the page loads whilst logged in as these users. In a nutshell, a tool like Charles will display all the detail surrounding requests made and responses served to the browser, including any failed responses.
I think it has to do with http headers, caching or encoding. But I cannot tell more without code.
Is output caching enabled for this page?
Can you give us the raw http headers for both the request and response?
If a white screen appears, will it be fixed by pressing ctrl+f5?
I have a problem in my asp.net pages
We are using form authentication. Once page is signed out I am able to go back to the previous page. This is due to pages cached in browser.
So i disabled the cache. But this has its own drawbacks.
If user is logged in he will not be able to navigate to the previous page using back button since no cache available in the browser.
if I have a file download in the page it wont work since cache disabled.
Even history.back javascript function also not the correct solution.
What is a permanent solution for this problem? I have faced with this all the time and never found a consistent solution.
Can anyone suggest a possible solution for this?
Thanks
SNA
You shouldn't need to disable caching. If you invalidate their session or authticket, you should be able to detect if they are signed out or not, in which case you can redirect them. This link may be helpful. If you are really concerned with the back button try using clearing the clients history via javascript after you log them out.
EDIT
Check out This Link It goes in depth on some of the different approaches. I don't think there is a sure fire way of keeping users from looking at previously downloaded content, but there are a few things you can do to make it difficult.
Is there a simple and foolproof way we can test an AJAX installation? We have a problem in calling a webscript using AJAX form a JS file. The error is 'ServiceLib' is not defined. The error gets a few hits on Google.
We've added some AJAX functionality to a customer's app. This works fine here in the office on dev machines and on our IIS Server, it works fine on the customer's test web site, but when we put the app on the live site, the webscript calls fail.
The customer installed AJAX on their live server a few days ago. We've verified that the service lib files are there and in the right places.
We've already spent hours on this with no solution and still do not know for sure whether there is something wrong with our code, or something is wrong on their server, or for that matter, whether AJAX is even correctly installed. Part of our problem is that we have no access to their live server, so there is not much we can do other than change lines in our own code, give the app files to our contact there, and see what happens. The contact knows less than we do, so we are working blind. A strange situation, I know, but there is beaurocracy involved.
Many thanks
Mike Thomas
Firebug might help - if you can get someone at the far end to install it, it may be able to give you an insight into what is going on with the ajax requests via its console, which logs and gives you the ability to view the return data of all ajax requests.
I'm thinking...
There are three parts to the process:
1) The client-side javascript logic in the browser sends the HTTP request to the server.
2) The server-side ASP.NET page processes it and responds.
3) The client-side logic receives the response and updates the web page, or whatever.
Swap out each part with something simpler and diagnostic to see where in the pipeline the break is.
For example, create a diagnostic webpage that's a substitue for #1 that calls the server-side page directly.
If that seems to work, create a different server-side ASP.NET page that's very simple, just logs something, to prove that the real #1 does what your diagnostic #1 did.
Ya know, your standard debugging binary search...