I have a very straightforward ASP.Net MVC3 application that executes an action on an index page which retrieves data from a database and displays a list of items. When I click an ActionLink for one of those items to go to a details page, and then click the back button (or hit backspace), it takes me back to the index page, but none of the data is there. Setting a breakpoint in the controller's action method shows me that the breakpoint is not being hit. If I hit F5, it then hits the controller and method.
This does not happen in Chrome or the latest release of FireFox, everything works as expected. It seems to be an IE issue.
Any ideas?
Thanks!
This could be because the action is caching although I would still expect the page to show the original values.
Try this. I prefer creating an attribute and decorating the actions with [NoCache].
Related
I have a contact addition form that can be navigated to from multiple screens in our application.
Once the form is submitted, I then take the user to a screen to view the contact that was added.
When the user then makes use of the back button it should take them back to the screen that they originated from.
This might be the Android back button or one that calls the RouterExtensions back function.
I have made use of the navigate extra replaceUrl when navigating away from the form to the view page.
I have also tried using the skipLocationChange extra when navigating to the form but this creates more issues.
I have created a simple playground page flow that creates not quite the same issue but does throw an error that I don't know what to do with either:
https://play.nativescript.org/?template=play-ng&id=BfVcGZ&v=2
In our app, by making use of the replaceUrl extra, the back button does take the user to the correct page.
However, there is a brief moment where they see the form again. This isn't an ideal user experience.
In the linked Playground I do get an error:
Cannot reattach ActivatedRouteSnapshot created from a different route.
This seems to tell me that replaceUrl is indeed removing the page from the route table.
However, the page isn't destroyed yet and so the app is trying to show a page that it shouldn't.
replaceUrl is not yet supported by Page Router Outlet, there is an open feature request, you might want to register your vote on the feature and follow up there for further updates.
I have a form that uses Html.BeginForm and for most cases this works as you would expect.
But in some situations I display a partialview that does several ajax calls to populate itself. When the partial view has been displayed I need to click the submit button twice to get the form to post. On the first click I can see the form refresh, and then on the second click the form actually posts. This is when using IE9, using Firefox the posts work on the first click.
I would like to know if anyone has seen this behaivor before I spend a lot of time trying figure this out.
Install Fiddler, open it up, and then reproduce the issue in IE. Fiddler will capture all of the requests, so you can see exactly what was sent to the server (and back).
Had a similar issue. The reason was, we had a in view and in addition we were doing $('#form').submit() as well. But the button didn't have "type" attribute. After setting button type=button. It was good.
I have a few pages in an Application that require A-Synchronous calls to be made for about 2-3 minutes to get Synchronized, the user may navigate away from that page during Synchronization and can come back again after visiting multiple pages and the sync continues all the time he is on other pages as well, when I go to a page from sync-page and press the Back button everything works fine.. but when i go to a page and navigate back to sync-page from Application Bar a new Instance of the Page is created and the Sync is just like Re-started.
Now i know every thing is working fine since new instance of a page is created when i call NavigationService.Navigate() , but what should i do in this scenario ? How to get the old instance of a page if it is there ?
Thanks...
You can't get an "old" instance of a page and it's not guaranteed that a backwards navigation will reload the previous instance of the page, it may be a new instance of the same page, but restored to the same state (assuming you saved any).
If you are trying to provide backwards navigation from the application bar then a) you probably shouldn't because that's what the back button is for, and b) you should make sure you use NavigationService.GoBack() instead of NavigationService.Navigate() because Navigate will always launch a new instance of your page.
If the page you want to get to is not the previous page, then it sounds like you are trying to implement non-linear navigation for which there is a recipe on the App Hub.
By the sounds of your scenario, you should handle this long running process separately (away from the view) and then display it's progress or results in a view when the user navigates to the relevant page.
I have a very strict requirement to use POST to pass in request parameters to my application upon entry. Once entering the application (page1), entering form information and continuing to the next page (page2) via a commandButton, the expectation is that the data will be posted and later read from a session scoped manage bean. All works well except when using browser back on page2 to navigate back to page1.
I have tried adding a redirect tag on the navigation rule that navigates from page1 to page2 to no avail. I have also tried this implementation of the Post-Get-Redirect pattern (http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html). Am I missing something obvious here?
Abel, the scope of page1 is request.
The solution we came up with which is no means ideal is to disable browser caching on the previous page. What this means is that whenever you refresh the page using the browser refresh button or click the browser back button, the browser will indicate that the page is expired and prompt a warning asking whether you want to re-submit the request.
We do have a work around which is to provide navigation buttons within the webpage but the idea was to support browser back. This would be easy using GET parameters, but POST provides additional complexity which we have decided to mitigate by by providing our in-house navigation buttons.
I am a beginner using ajax and I always thought that it is completely asynchronous. But I discovered that a call can be interrupted by a page reload or a page change (like clicking on a hyperlink). I was under the impression that when an ajax call is started, it is carried out no matter what the browser does afterwards. Is that wrong?
Now to the specific problem I am having: think of an online test where users answer questions (by typing into textboxes). When a textbox loses focus, an ajax call is triggered which persists the value of the textbox to a DB. That works well when changing between textboxes. However, I also have a submit button which triggeres a post action to another page (it is the submit button). When I enter something into a textbox and click on the button afterwards, the call is not carried out. Moreover, when I type into a textbox, click somewhere else (also triggering the call) and swiftly click on the submit button, the call is also not made. Is that expected behaviour?
The reason I am using ajax in the first place is to persist the values so when something unforseeable happens, like a browser crash, the already typed in text is already saved.
Is my way of thinking wrong? How would you go about solving this problem?
Thank you for your time!
AJAX is asynchronous.
When you send an AJAX request the javascript engine sends it off and sets up a handler for the response.
However, if you send an AJAX request to the server and then navigate away from the page before it is received, nothing will happen. Why? Because with each page load the entire Javascript environment is tore down and reinitialized, it has no idea what happened on the last page.
For your problem I would intercept the form submit action and do whatever you need to do with the data, and then submit the form.
Edit: In response to your comment. You are correct. If the ajax request is sent, and you're not depending on it's return value, then it should not matter.
I'd suggest debugging your problem with Firebug to see if the AJAX call is really being sent properly, and to confirm your server is properly processing it.
Unless you do something special with persistent local storage, all javascript and ajax calls are blown away when a new page is loaded over the current page. Also when a submit is done on a form.
To save things intra-page, save the data asap. Eg, perhaps save on key-up, perhaps periodically with a timer, not just on lose-focus.
Re submitting the page: change the on-click behavior to first store, then to go to a new page.
All of the effects that you are seeing are normal.
Also, be sure to test on both slow (ie 6 or 7) and fast browsers (chrome)