Kevin it would be great if you could post your findings as soon as possible. We are currently holding off on a big marketing push as it is figured our buyers will not tolerate going back to page one after a back button press.

If you are interested, we could also pay to fast-track this. It is currently number one in our issue tracker.

Hello zymmetrical,
Handling the browser back button is a notoriously difficult process in web development. Simply google'ing "Browser back button" you can see the extent to the problem. This problem is compounded by using Ajax. Each browser hands the back button in different ways. You could get it right for IE and mess it up for Firefox. Then when a new version of the browser comes out it could be wrong for both. Many times the overhead of finding a page could be minimized by:

#1 providing a better search mechanism to limit the results down to one or two pages. In a search structure you could always store the search values in the session and display them on the screen for the user to see.
#2 a better design. If you are presenting too much information the ask, "why am I really trying to show too many things for the user to choose from and find?"
Otherwise, if it truly cannot be eliminated, then you are stuck with the problem you are specifying here. There could be "hacks" to solve the problem. But as with all "whack-a-mole" solutions, something else invariably pops up.
Thanks,

Yes it's definitely a pain, I just saw a glimmer of hope as it sounded like Kevin was close to getting this issue licked within the Listx architecture.

For us, an acceptable alternative would be a big button that says 'Back to Search Results' and initiates a ListX action: would this be easier to implement the desired behavior with as opposed to the browsers back button? I'm sure the users would learn pretty quickly to use a button explicitly to return. At the least it would be better than the confusion that arises now when they hit 'back' and go to page 1 again.

hey zymmetrical,
Having users use your navigation methods instead of changing the behavior of the browser is always a better option. I believe many internet users are getting used to it. That is why good navigation is critical. Other then that, you could use the session a bit to store some temporary state, but that can be dangerous if you start to over rely on those values in your source. Often we have put messages at some point in the process urging users to use the navigation inside the web page as opposed to the browser navigation. Some sort of message like:

"Please use the 'back' button on the page instead of the browser or else you could destroy the world and life will cease to exist as you know it. If you feel that you accidentally could have jeopardized humanity, then press the reset button to start from the first page. Thanks, mgmt"
Thanks,

Ok but the million dollar question: how specifically do we implement a back-button approach to return to the previous page? I don't see much danger in it, if there is a Session value present, the the results page goes to that pagenumber, if not, back to page 1.

A specific example of this approach would be greatly appreciated this issue again is our biggest problem (amongst a slew of others).

Hey guys, just to give a quick update. I have identified a solution for the back button management and AJAX within the ListX and the upcoming OWS products. The handler for this will be specifically recalling the *LAST* page that was viewed by utilizing the Anchor of the URL specifically. This structure works well in my demo environment. Basically what happens is this:

Assume you go from a Control Panel to a Grid
The pager links on the grid replace the current URL in the history with a URL containing a specialized anchor. For example:
For page 1 where the grid's module id is 123 -
http://www.bi4ce.com/default.aspx#Page123:0
For page 2 -
http://www.bi4ce.com/default.aspx#Page123:1
For page 3 -
http://www.bi4ce.com/default.aspx#Page123:2

Lets say you have another module grid on the same page - Module 777 and you have already paged 123 your url ends up like this:
For module 777 page 2
http://www.bi4ce.com/default.aspx#Page123:1#Page777:1

Now when you click a detail record or another link you would go to that page -
Back from the detail would go to
http://www.bi4ce.com/default.aspx#Page123:1#Page777:1

The Javascript automatically parses the 123 and 777 module page numbers out of that url.

Clicking Back again will take you back to Control Panel.

The best part of this handling - its ONLY dealing with the Javascript layer!