ASP.Net Form's fields empty only on customers's env - asp.net

I was given a task to solve a bug on some old project that someone else wrote.
The project is ASP.Net deployed on IIS.
Scenario:
Open Request form.
Fill personal details.
Click button "Add Items" to open items selection window.
Select items and close the item selection windows.
Expected:
Back in Request form, it is now showing both the personal details, entered in
step 2 and now, on the same request page, the list of selected items, selected in step 4.
Actual:
Back in request form, not showing personal details and only showing
the selected items.
From the code I learn that every field on the request form is:
Saved to the session (E.g onChange in JavaScript call code-behind save
function)
Load from the session on Page_Load
I guess the above is needed as a replacment machanism for the ViewState,
because in the above scenario it is required for the form fields (E.g personal
details) to persist across several pages. (The opening of other windows
to add items...)
Also from the code I learn that items added on "Add Items" windows are:
Saved to the session in the page "Add Items"
Loaded from the session in the Page_Load of page "Request"
Now instead of working on the project over at the customer's offices we copied
the project and deployed it back in our offices - only problem is now it is
working fine - that is, both the personal details and the list of selected
items are showing as expected.
I would like any suggestions... What could be the cause of such
behavior?
Also in case I will not be able to recreate the problem on my environment,
what should I check/debug on the customer's office?

...What could be the cause of such behavior?
Based on your symptoms, it sounds like could be happening is the server is relying on a client-side script (to set the form values sent down from the server's response) that has a dependency (e.g. jQuery) that might not be supported by the (possibly outdated) browser being used.
...what should I check/debug on the customer's office?
Here is what I gather is supposed to be happening after the client has the form open:
User enters values in form control(s). ("Personal Details")
Client-side event handler sends asychronous requests to the server (no callback) in order to save form values to the user's Session.
User clicks a button. ("Add Items")
Client-side event handler opens a new window that sends a request to the server for the "Items Selection" page.
Response is received from the server and the "Items Selection" page is displayed on the client.
User selects values for controls. ("Items Selection")
User clicks a button ("Close Window")
Client-side event handler:
Sends a request (with the "Items Selection" values) on behalf of the previous window to the server for the "Personal Details" page.
Closes the current window.
Previous window receives response, page reloads completely, and all form data is still present (reloaded).
We know at the very least 9. isn't actually happening properly, since this is your stated problem.
Assuming I have your implementation correct, you should start by determining how the values are supposed to be written to the controls during the last step (e.g. server controls' values assigned directly or server registers start-up client-script to write the form values). Then you should check the values that are sent to the method you discovered. If the values are incorrect, keep backing up to each previous server request to see what is the resulting Session state before the response. If the values are correct then you know something is going wrong (most-likely client-side) after the client receives the response from the server (I think this should only happen if my jQuery theory above is correct).

Related

Difference between "Reload this page" and refresh a page from address bar

I'm working on an asp.net web app. One of my web page received a posted value from a remote server:
HiddenField1.Value = Request.Form.Get("something")
And further on I'm using javascript to manipulate value from this HiddenField1.
The weird thing's that if I clicked on the "reload this page" icon on any browser:
reload page icon
page's reloaded and HiddenField's value's there
However if I moved mouse to the address area and clicked on the url,
address area examplethe url string's background turned blue and I hit Enter key,looked like the page's behavior's exactly the same: reloaded. However, the HiddenField's value's gone.
Any hint what's the difference between the two scenario?
This is not strictly related to ASP.Net: it is actually a common browser behavior and you would experience the same with a different server language (php, python or whatever).
In your second scenario, the browser will send a new (GET) request to the server, asking for the last loaded URL. It would be the same if you just type the address starting from a blank Address area.
In the first case instead, you are telling your browser "please, repeat the last request you made". Maybe it was a POST request sending data (form fields) to the server, and the server did answer to the previous request inserting the hidden field you are noticing.
To recap, the second scenario is "send a GET request for this address, ignore everything else". The first is "Repeat the last request you send. If it was a POST request with form data, send it again as the time before"
Very likely in your case, the server code inserts the hidden field just in case of a particular POST request (possibly according to posted data), and not for a GET request
If you don't know the difference between POST and GET for an HTTP request, this answer can be helpful

Avoid hidden field in the web forms

I have a web page and a modal dialog page. On clicking the save button in the show modal dialog. closes the window and returns a value. Now when the
control reaches the JavaScript function of the parent window . I wnt to perform some database operation on the basis of this returned ID.
I am using the following approach to utilize this returned value.
Keeping it in the hidden field and populating the returned value in hidden control.
keeping a hidden button in the parent window, performing the click event when control comes back to JavaScript function of the parent page. Thus in the server side button handler get the value from hidden field and perform database operation on the basis of returned value.
Is this approach fine. Or I can get rid of hidden field
That's not terribly bad provided the ID returned is not sensitive information that someone can use to modify a record that doesn't belong to him. One can perfectly manipulate this ID on the client side for any other ID and have your logic update a different record from what you intended.
If all you are doing is calling a server side method passing this ID; why don't you do the whole update from the pop-window itself (at that point you already know the ID)?
If the parent window (page) is meant to be updated; you can just perform a normal refresh of the page (ie. use window.location to redirect the user to the same page so he can see the update or use Response.Redirect to the same page.)
What you're probably looking for is called AJAX. With AJAX you can communicate with your web server from within your JavaScript code directly. No HTML form posts are required then. You might want to look at frameworks like JQuery. These have easy implementations (cross browser wrappers) to send HTTP requests via AJAX.
Note: I just noticed, you are using ASP.NET. Take a look at ASP.Net AJAX Page Methods.

Detection of page refresh / F5 key in ASP.NET MVC 2

How would one go about detecting a page refresh / F5 key push on the controller handling the postback? I need to distinguish between the user pressing one of two buttons (e.g., Next, Previous) and when the F5 / page refresh occurs.
My scenario is a single wizard page that has different content shown between each invocation of the user pressing the "Next" or "Previous" buttons. The error that I am running into is when the user refreshes the page / presses the F5 key, the browser re-sends the request back to the controller, which is handled as a post-back and the FormCollection type is used to look for the "submitButton" key and obtain its value (e.g., "Next," "Send"). This part was modeled after the post by Dylan Beattie at How do you handle multiple submit buttons in ASP.NET MVC Framework?.
Maybe I'm trying to bend MVC 2 to where it isn't meant to go but I'd like to stay with the current design in that the underlying database drives the content and order of what is shown. This allows us to add new content into the database without modifying the code the displays the content.
Thanks,
Michael
The recommended way is to use PRG pattern - Post-Redirect-Get. Meaning: after submitting, redirect a client to Index or what, causing only reloading Index when user hits F5, not posting the data again.
Check this: http://en.wikipedia.org/wiki/Post/Redirect/Get
And this: http://www.google.sk/search?q=prg+mvc+asp.net

Difference between Page refresh and Page postback

My question is - what is the difference between page refresh (if I press f5) and postback (If I press a button)?
Can anyone please tell me?
Thanks in advance.
A refresh mean a complete reload of the page, without any form data. This is essentially an HTTP GET.
A post back is when the page is posted to itself (through the form action=""). This is essentially an HTTP POST.
Lets have the actual difference between refresh and explicitily submitting a page :
1) Refresh does not mean to post back the page with get method..(You can check it with response.write request.form("some input type")).
2)Difference lies with the data sent to the server :
in case of explicit submit form is submitted with latest value(i.e it recognize the changes in form elements)
But in case of refresh, form is submitted with default form value.(i.e if you change the value of form element it will not reflect at server.)
when page is refresh that means page is sending request to server without any data that means HTTP GET but in another case suppose a event is fired that causes postback after
page completely load on browser if we press f5 or do refresh then it will send privious data with request instance, that means again for that data server will perform operation...
have u seen somtimes while you are doing online sopping after selecting item and press accepet button uyou get total price ,now again if you refresh then for that selected item it will again go to server that means you are buying same things twice.....i think now you get everything what i want to say...
in when page is postback then code of that page again compile and also processing `request data`. this process will going on

ASP.NET State Error

I am have an asp.net page, where a list of products is shown in a drop down. When a user selects an item, corresponding price, available quantity etc. are shown in the corresponding text boxes. I have used ajax update panel to retrieve these information.
This approach seemed to work nicely at first, but sometimes when a product is selected, it takes too long for the price, quantities to change, and sometimes they don't even change. Then I used firebug to see what happened to the ajax request, and I found out that the response that is coming from the server is something like this -
70|error|500|The state information is invalid for this page and might be corrupted.|
I have absolutely no idea what is wrong here.............
It might be a timing issue since you mentioned that sometimes it takes awhile for certain parts of the page to render on selection of a dropdownlist value. What might be happening is that when (quickly) selecting another, different value from your dropdownlist is triggering an ajax callback to the server before the current page request has finished rendering.
What this means is it is possible that the Event Validation field (__EVENTVALIDATION) value that is part of the page has not been rendered yet and therefore is not sent back to the server. ASP.NET uses this value for security reasons on postbacks to ensure that it originated from the same page and not some bogus page. If it is not provided in the request then ASP.NET assumes that it is a different page and therefore returns that specific error message.
You could disable event validation but that might leave your web app vulnerable to attack especially if its public facing.

Resources