Enable AJAX history in SharePoint Webpart pages

The problem:
You want to enable the back button in browser for the actions that are done through Ajax calls. It is pretty simple in a normal .NET 3.5 aspx web app. You can find the quidance here.

However this guidance did not work for me in a SharePoint webpart page. The history points in the back button browser history worked fine, the problem occured when I actually clicked the back button. The page changed back to the previous page  and then came back to the original page. After some fiddling I found out that this is because the __eventtarget parameter in the history page request is wrong. The parameter was set on the button and not on the scriptmanager as it should be. Therefore the button event click was fired when the history page wass loaded and then the original page was loaded again

The solution:
Create a new custom web part page. See Ted Pattison guide how to create a custom web part page. When done modify it and add a ScriptManager directly into the aspx code of the web part page. From now the browser history should work correctly.

Note:
When I used the Publishing page I did not come across this problem. Why? Did not have time to find out. 🙂

Note2:
This feels rather like a workaround, if anybody ever reads this blog and has a better solution please let me know.

Advertisement

The SessionId is different with every request.

This problem can because nothing was written into the session and therefore the session is forgotten with the end of the request.
What you can actually do is to save something into the session during the request and everyting should work fine.
For example:
this.Page.Session[“dummy”] = DateTime.Now;
There are also some other good recommendations and gotchas here:

RunWithElevatedPrivileges behavior in different hosts

	Normal code	RunWithElevatedPrivileges
w3wp.exe	account of the currently loggedin user to sharepoint	account under which runs the “sharepoint web application” application pool
owstimer.exe	account under which runs the owstimer.exe service default it is NETWORK SERVICE	account under which runs the owstimer.exe service default it is NETWORK SERVICE

As you can see runwithelevatedprivileges in owstimer.exe has no effect.

Custom membership provider:

Under which account runs the request when you use custom membership provider and there is no windows account associated with the user logged in to sharepoint? From my observations it is “Internet Guest Account”.

owstimer must be restarted after solution deployment

True….