On my two-page web application, users progressively enter info and make selections on page one. When done, they click a 'Generate' button that navigates to page two. Users print that page and hit the browser's Back arrow to return to page one with selections intact.
After a few generated pages (2 or 3), clicking Back just disables the icon without going back. They have to manually revisit page one, reentering their info and selections.
I found that the down arrow to the right of to the Back / Forward arrows (IE8) that shows the immediate history generally includes all 'previous' pages. But when the back button is about to disable on click, the history only shows the current site.
What events, scripts, headers, etc. clear the history for the current site? It occurs in IE7 and IE8 on WinXP and Win7. In FireFox, the button did not disable, but it did not do anything either. Users report it as a recent and I have been making changes to the application, but it only affects the HTML on page two (not scripts, though). It's probably a code issue if it's recent, but I'm not sure what to look for when double checking my recent changes.
Which version of IE?
Internally, IE maintains a limited amount of data in the travellog (aka back/forward stack). ASP.NET pages with huge postback forms often blow this limit, wiping the history stack.
In IE6 and IE7, if there is a form input field with a value longer than 523,659 characters, when you navigate away from the page, IE may clear the current session's travellog (similar to history), disabling the back and forward buttons.
I believe the overall Travellog size limit was upped somewhat in IE8, but it's not more than a few megabytes.
As a general rule, if you want your users to navigate back and forth between pages, I would give them links on the page that do the job (without using javascript:back()) instead of using the browser's navigation.
What's happening, most likely, is that the postbacks of a single page are sometimes considered pages, sometimes not. If a user action loads a page that has the same URI and query string, most browsers consider that "the same page" even though EVERYTHING may have changed. This is usually due to heavy use of MultiViews with the information about the current view kept in ViewState or Session; navigating within that page doesn't change the URI being navigated to, so the browser doesn't log each new load as unique.
If you really need proper back-and-forth functionality, you will need to make sure that every link will result in the browser being told to navigate to a different URI than the current page. You can do this by adding a query string element that will be present in every link to a different page or view, that will auto-increment with each click the user takes. This gives the browser a different URI every time. You only use the existing QueryString element to create the new one on your links' URIs. This can get cumbersome, and the easier solution is simply to provide in-page navigation and tell your users not to hit "Back" any more.
Related
I have a grid view and an edit button in the grid view. On edit button click I am opening a new aspx page that has text fields for input the data. When a user copies the URL of the gridview and opens it in a new tab of any browser then click on the edit button for two different records. If the user changes anything in the first tab and submits it. It changes the info for the record on the second tab. It is happening because I am passing userid in session to the form aspx page and session got updated when user opens the second record in the new tab.
Are there only two ways to passing data to aspx page?
using session
using a query string
I don't want to use the query string.
Please help thank you.
You are writing a ASP.Net application, so at the end of the day there is only that much you can do. You can request some things off the browser, but if he actually does it is entirely up to it.
You can make it unlikely to happen by accident, using the HTML Links target property. This requests the browser to re-use any alread open tabs for this record. But that will not prevent a dedicated person from still opening 2 copies.
A pretty simple way to avoid race conditions in general, is the SQL rowversion column. You retreive the rowversion with the rest. You keep it along in a hidden formular field (that is what they are there for). When writing the update, check if it still matches before the write. If yes, you update. If not, somebody has modified the record since then and you reject the update. Can be the same user in another tab, can be another user at the end of the world. Could be that this tab was opened a year ago, surviving on sleep mode. It does not mater - any change trips this protection.
We have a custom session handler which stores a history of data for pages. We have a requirement where we need to store and identify unique sessions for every tab/window.
For simplicity let's just say I need a unique string for each tab i.e.
Window A - Tab 1 - ABCDEF
Window A - Tab 2 - CDEFGH
Window A - Tab 3 - EFGHIJ
Window B - Tab 1 - GHIJKL
Window B - Tab 2 - IJKLMN
I need these strings to be accessible immediately when any link is clicked or when any tab performs a postback.
We have an overly complication solution in place at the moment which generates these unique strings and saves them in the tab name and cookies and uses the window blur/focus events to determine when a page has been navigated away. It works well 'in the lab' but we do get problems with this 'in the wild'.
I guess the most 'reliable' way to do this would be to generate a unique string and place it on the querystring for every page and every URL on that page, that way it would be available immediately as you click on any link or post back, and you could move between tabs / windows freely. However that would take a significant rewrite and I wonder if I'm missing a more straightforward option.
Any suggestions welcome.
In the end we found an ideal solution to this. We don't have 'unique' sessions between tabs, we have 'unique' sessions for every page, ignoring tabs entirely.
We still use the blur/focus events to handle which tab the user is currently on, but that is only used to provide tab specific navigation history and is nothing separate to the session handling.
This seems to work well for our needs.
We have an application where we have a single level navigation menu with some heavy-duty pages on each link. The user can switch back and forth between these pages frequently to obtain information that he needs.
Once the page gets generated, it wouldn't change for the session. However, the page is specific to the user, hence we cant cache it.
I was trying to come up with a solution where we generate the page once, and keep it hidden in the background until its link is clicked, but haven't been able to get my head around this.
One of the ways I thought was to have multiple div tags (one for each page) on one page and keep toggling the visibility as the links are pressed, but that would end up making this single page very heavy. Someone also suggested using iFrames, but I am not really comfortable using the iFrames much and I'm not even sure, if it would be any helpful either.
Can you guys please suggest a few approaches to tackle the issue?
update: Just to clarify, we are fine with keeping the pages separate and navigate across using a standard menu bar. We were just looking for ways to optimize the performance as we know that the pages once generated wouldn't change and there should be some way to tap that benefit.
You can use Ajax tab control for this purpose
Try taking a look at this MSDN article which specifically tackles the issue of how to user-level cache. Also, it might be more manageable to break each tab into a user control. That way your ASP.NET page has just the tab control and 1 user control for each section under the tab. It makes managing tabs much easier.
EDIT:
What I would do in your case, since you say the data won't change for the user, is I would grab the static data from the database and then I would store that data in the Session cache. THe session cache is specific per user and you can try to retrieve the static data from there instead of repetitively calling the database.
Check out the ASP Multiview control. Just remember that even though the different views are hidden when not active, their viewstate is still being sent back and forth. Can be a benefit if you need to check control values across views though.
I'm using an usercontrol (*.ascx) in a CMS system C#.NET
I've got a Gridview which displays address. You hav a link on the line items and you can click on the items (link) which navigates to other page with querystring info and displays the detail information. When the user clicks on cancel/back it returns the the overview page. Both are separate programs.
When the user clicks on Next, Next, Next e.g. page 7 is displayed. So clicking on an "adres link" on Page 7 will open a new page and when the user comes back it should display page 7 back again.
I was keeping the page numbers in a session. so when the user comes back it reads the pagenumber from the session. This works fine. But the issue is this module is used other placess too, and also in other portals (which uses the same module)
So when have clicked next next etc and you are on page 7 and then you open another portal or other Porgram which have the same module, it displays page 7. Because it reads the Session variable and sometiems it gives a dump because page 7 doesn't exist, because no much records.
Viewstate fix this issue, but everytime after clicking the adres item and coming back it displays page 1, which is not what I want.
As I said, I use the same module in other pages and other portals (same program with different settings CMS -system)... So where and how do I need to store the pagenumbers so it doesn't have conflict with other pages and other portals?
ViewState["page"] = 7 -> starts on page 1 always when you come back
Session["page"] = 7 -> page number is shared....
Why don't you keep a Structure or Dictionary instead of simple int in the session. In this you can store Page as well as the Module.
I believe you need to think about instantiation. It seems that you need to isolate each instance of your CMS so each one will share its own set of server variables, includinig session ones.
Well, it's true you're using some ASCX control, but you can have some "application identifier" so any of control instances can have their own set of values.
Anyway, storing long objects in session is a bad practice, since other modes than "in process" will serialize objects and deserialize them whenever you access to session's state.
Maybe you need some kind of custom session management in order to optimize performance and memory usage so your components will be rightly isolated and they will remain performant.
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.