TL,DR: Firefox (and only Firefox) fails to display the right select child element as marked with selected="selected" upon clean refresh of a page, even though it is correct in DOM (but only under certain conditions).
(I do not believe this is a duplicate of HTML select, correct option selected in DOM, but wrong item shown in firefox as I am not using ember.js.)
Background
I'm building a "software management/update server" in ASP.NET WebForms. It stores master copies of applications and serves downloads and updates via a simple API. Each application (or "App" as they're referred to in-code) has a DeptID and a GroupID, which are GUIDs, relating to respective Dept and Group tables. Each Group has a DeptID field also.
On one particular page, used for editing a chosen software application's details, NON-postback requests (.e.g., http://localhost/admin/app/edit.aspx?id=guid-here) will result in calls to the database to populate field data on the page.
In brief, the ASP.net runtime Page_Load event does the following:
Ensures that this load is not a Postback
Verifies than an id parameter was provided in the query string
Populates options in the ddlDept DropdownList (renders as HTML select element) from the Dept table
Pulls all fields from the App record from DB as matched by id into a DataSet
Populates options in the ddlGroup DropdownList (another select) from the Group table, matching the DeptID pulled from the App dataset
Populates the data for all form fields from the App dataset
Important to Note: When you click Save, the page is posted back to the server and field data dumped into the database. If the save operation is successful, the browser is instructed to redirect to the current page's URL using Response.Redirect(Request.Url.ToString), resulting in a "clean load" (non-postback load) of the page.
Expected Behavior:
After the page has been successfully saved, hitting F5 or clicking refresh should result in another clean load (non-postback) of the page, and all fields should be populated just like a direct URL hit on the page.
Actual Behavior:
After the page has been successfully saved, hitting F5 or clicking refresh reloads the page as a non-postback (verified in VS debug), but the ddlGroup select element renders the "default" / first item ("Select One") instead of the item marked selected="selected" in the DOM.
I have stepped through every single line of VB code in debug — and when the server sends the page back after this "post-save" and supposedly "clean" load, the ddlGroup value is correct in code all the way out the door. Only in the browser, and only Firefox specifically, is the displayed value set to the wrong item, even though it's right in the DOM. Refreshing again doesn't help at all. When I try to save again, the RequiredField validator for ddlGroup complains that the field isn't valid, even though, again, it's supposedly right in DOM.
This seems to me to be a very bad Firefox bug.
Thoughts?
So, this isn't really what I consider a proper "solution," but rather more of a stable work-around.
Adding autocomplete="off" to the offending select (DropDownList in the aspx markup) magically prevents Firefox from messing up the displayed element within the select, thus always showing the correct one that is marked selected="selected".
I've gone ahead and added it (and will add it) to all of my DropDownLists / selects from now on... thanks Firefox.
Related
I simply need to copy the textbox input data to another page. i have a datagridview from Home.aspx when i select data from it. it will display the row data to the textbox. now i want to copy/pass the data to another page. how can i do that? i tried following codes but it does not work.
This is the 2ndPage Code on load_page
If Not Page.PreviousPage Is Nothing Then
Dim SourceTextBox As TextBox
SourceTextBox = CType(PreviousPage.FindControl("TextBox1"), _
TextBox)
If Not SourceTextBox Is Nothing Then
Label1.Text = SourceTextBox.Text
End If
End If
Ok, a truckload of issues here.
First up:
page.previouspage is ONLY available if you used
Server.Transfer("~/MyCoolWebPage.aspx")
And as general rule you don't a "server side" transfer/jump/hop to a page this way. Trying to keep this post short, but a server.Transfer() means that no real browser side jump to the page occurs - only a server side transfer. That means that the previous URL does not even change! And thus as a general rule, a jump to a page occures from a button click on a page, and that button click can be a client side (JavaScript) click, or a standard button click that executes the Response.Redirect(). However, in both cases, it really is a client side browser request. You as a general rule thus don't want to build or write a web page that "assumes" that a Server.Transfer() was how you landed on that page.
Because of the above? Well me.Page.PreviousPage is ONLY available if the page you are landing on was the RESULT of a 100% server side re-direction to a new page. And that simply not going to be the case, and thus for the vast majority of your web pages, then page.Previouspage will be null, and of ZERO use to you. (it's simply not available).
So, now we back to traditional means and approaches to "transfer" data to the next page.
Remember, that page is state-less. That means EVEN on the same page, all values, and variables are lost between each page load. Even a simple button click means the page will re-load, but that re-load will see all your values lost. Now most controls such as a text box, or even the gridview can and will keep what is called their state for those "round trips" when you click say on a button.
Now, in your case, no doubt you are clicking on a button, and jumping/loading to a new web page. Thus, all previous controls, data and everything you had in existance on that previous page is all gone, and lost.
So, how to pass values give this "state-less' nature of web pages?
Well, a very common way is to use parameters in the URL. However, I find them quite ugly, and users can also mess with those values. However, for really large web sites, we see the parmaters in the URL often used, and that's because the web site does not want to spent the energy, the time and even the memory and resources to keep track of say 1 million users hitting that web site.
But, there is another very common means to "save" values in what we call a round trip. That handy dandy "temp" storage system is called Session(). Now Session() should be treated as a precious and limited resource, but it is quite much how you can (and should) pass values around. The beauty of these values is they "persist" and keep their values between post-backs. And this includes jumping to another page.
So, to pass that data to the next page?
Simply stuff that data row into the session, and then in the target page, you can then get/grab/use/pull any values from that one row of data.
So right before your response.Redirect("to my 2nd page page"), you can do this:
Session("MyTextBox") = me.TextBox1.Text
Now above is fine for one text box value. But, you want to pass the whole row.
So, you can go:
Session("MyListDataRow") = MyRowOfData
Now, you don't explain how or when or where you selected the one row of data. But you can certainly shove the one row of data into session, and then show/display it on the next page.
One more SUPER DUPER WHOPPER:
If you do pull out the selected row into a datarow (as opposed to datatable, or dataset), then keep in mind that .net serializers don't support the datarow (why, I have no idea!!!). So if you using "in-memory" sessions(), then you are ok. But if you ever decide to adopt SQL based session() management, then that code will start to fail. So, either shove in a ListViewDataItem, or a datatable to pass that row of data, and not a datarow.
I would thus just not pass a "datarow" in Session() and avoid the above horrifying revelation that .net left out that data rows don't support serialization! (holy moly!!!!).
So unless you are using a server.transfer() for this, then page.previous is not valid nor available. And if you using a master page, then you have to first dig and get the master page refernce, and then the ContentPlaceHolder if you ARE using a server transfer and you thus do have use of page.PagePrevious.
Edit:
Having said all of the above? Well, if you have a click event on a listview (or datagrid) row, then a server.transfer actually is "one" of those good use cases in which you may VERY well consider a server.transfer(), since the you have full use of the listview/datagrid data in that 2nd page though use of page.PreviousPage. Just be aware that you have to pull down one more level to get at the content if you using master pages.
I have a web page written in ASP.net where it finds a list of employees, displays them in a listview and allow the user to change different statuses for each employee.
On each row I have employee information like name, date of birth, address and then 4 status fields that are displayed as checkboxes and a comment field where the user can type a comment explaining why they changed a certain status.
Currently in Listview, there is an edit, delete button when they click edit, the checkboxes and text field are displayed the user updates them and click save.
asp.net will do a postback to save the changes for this row and then fetches the data again to refresh the list.
The problem I am having is the list is very large (more than 3000 names), so I am using pagination to show 50 to 100 names on each page. This is still a big performance problem because after every line update a query needs to run to fetch those names again, and with ASP.NET the server is generating the html and passing everything to the browser.
The customer wants the page to be mobile friendly too, so I am thinking to redo the page using Angular on front end with web-api or mvc.net on back end that returns JSON.
My question is there an easy way to do this and allow the user to change the status for multiple employees on the same page at once and then click one submit to update all the changes? if I do it this way, there will be less queries to run and it will be faster for the user because they don't have to wait after every line update.
Any examples will be greatly appreciated, unless there is a different way to implement this, in this case please let me know.
I have a thought that may work.
On load render names and use pagination.
Then use ajax to send the post to server and change data in database.
When editing has returned successful then only change the values that have been edited using javascript for the user to view.
I am currently working on a site for an auto dealer and ran into a bit of a snag when I started trying to ad pagination to the inventory page.
The inventory page has 5 search options type, make, year, model and trim. They are all drop downs and they are all populated by a live feed, changing the options autopostback the page and the inventory/nav are updated accordingly.
Everything was working great until I went to add pagination to the page. The pagination works fine for what it is, if there are more then 15 results it adds a numbered nav to the page that allows the user to jump pages.
4
The problem is when they do jump pages all of the search options revert to there original settings, and when the page loads its pulling in every car again instead of what the user searched for. I can't really figure out what the issues is, I expect the state is getting lost when the user clicks the link even though it is to the same page. I tried using sessions but it seems to have muddied it up, does anyone have any suggestions for a fix?
If you require the code I can link it, I warn you though it is a pretty large amount of code and I don't think you could find much in it, but who knows.
Try using a LinkButton control with an OnClick event. Do whatever you are doing when you test for the "page=4" querystring parameter in the OnClick event. You are losing state because the a regular html anchor tag causes the page to load as if it were the first time you visited and ViewState is blown away - Page.IsPostback is false.
If you don't want to use a sever side control, you could always pass the search parameters in the query string.
4
If you do it this way, please be sure to sanitize your inputs before you pass them back to the database.
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.
I am working on a legacy web application written in VB.NET for ASP.NET 1.1. One particular page has a form with a number of fields. In response to a drop-down box changing value, I am clearing a number of fields, resetting a number of drop-down boxes to the first option, and setting them all to "disabled" in the UI. To do this, I'm using jQuery. I add a CSS class to all of these fields, and then my jQuery selector is something like the following: $("*.my-css-class"). Here's some sample code to explain.
var fields = $("*.fields");
if (some_condition) {
fields.val("");
fields.attr("selectedIndex", 0);
fields.attr("disabled", "disabled");
}
The UI updates as expected in response to the above js code, but when I post back the page in response to a button click, the original values still persist on the server-side related to these controls. For instance, txtSomething is one of the fields with a CSS class "fields" (so it will get selected by the above jQuery selector). The user types "1234" in this text box and submits the form. Either the same page is posted back to itself retaining its values, or I return to this page and prepopulate the values on the server-side (for example, the user clicks an Edit button on a summary page), so the control txtSomething is initialized on the client with the value "1234". My jQuery code clears the value as far as the user sees it in the UI, and then the user clicks a submit button. If I interrogate the value with a jQuery selector, the value of this field is an empty string. When the page is posted back and I'm stepping through the code (or doing something with the value of this control), it is still "1234".
A very important point to make is that these values are sent back to the browser after being submitted once. So, picture a form being submitted, or any case where these values are bound or set on the server-side and outputted to the browser pre-populated (as opposed to being output to the browser with default or empty values). If I load the page as default (empty text boxes), enter some text, and then trigger the js function to clear these fields, the value I typed never makes it to the server.
why do you need to disable those fields? Disabling controls can make them not post values to the server ... at least that is what happens when an asp.net control is disabled server side.
Update 1: couldn't take having the doubt if it was only server side, so I looked it up :) http://www.w3.org/TR/html401/interact/forms.html#h-17.12.1 ... "In this example, the INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.", so I was right, even when disabling it client side it won't post the value