User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 We noticed in several versions of Mozilla, including the latest stable release, 1.3, that on at least one of our pages, if you hit reload, the default selection in the select boxes is incorrect. I have setup a page at the above URL where I can reproduce the bug every time. I have verified the page is HTML compliant. Reproducible: Always Steps to Reproduce: 1. Load http://www.winzig.com/mozilla/selectbox.html 2. Press the reload button. 3. Notice the select box is no longer on the default. Actual Results: The drop-down went from having the default option selected to having the last option selected ("TEN"). Expected Results: It should have retained the default selection. I can also reproduce this bug by leaving the page, then going back to the page. The behavior is the same as if I reload the page. The only way to get the select boxes to reset to the correct option is to go to the URL again directly (not hitting reload).
Mozilla remebers what the values are for forms elements on reload. The problem is that your <select> has multiple entries with the same value. Mozilla dosn't know which option to pick so it picks the last one. NOTE: You can force mozilla to forget what the values are by Ctrl+reload. This is like bug 166168 . The difference is that this bug deals with value="foo" and not value="" being repeated in <select>.
D'oh shift reload will force mozilla to forget what the values are on reload
What use would remembering the index be? The value may actually mean the same thing.. See also bug 46845 (but that would not help with session history, of course)
It's already covered in the other bug, bug 166168. You are losing information if you only retain the value that was selected. By only remembering which value was selected, you are discarding the information that described which option was actually selected. Since it is not illegal HTML to have two options with the same value, it is confusing to end-users if their choice appears to have changed even if the [hidden] value is the same. The page designer clearly has their reasons for having two or more options mapped to the same value. For example, they could ask a question which to the end-user could have different responses, but for the designer's purpose really boils down to one or two hidden values. I haven't looked at the code used to fix bug 166168, but wouldn't it be faster and take up less memory to store the selected index rather than the selected string value, anyway? Could you explain why with the current code in place the bug no longer manifests with empty values, yet it does with non-empty values?
We remember the options by value if there is a value, or by index if there is no value, because of the much more serious problem of reloading a page when the select box has changed (which happens often, for example in the bugzilla query.cgi page when you have changed the Components dropdown). Selecting by index is not enough because it could select exactly the same option as before. We could possibly fix it once and for all by always storing both the index and the value (together) and first trying by index, and if that doesn't work (the value has changed), trying by value.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 232312 has been marked as a duplicate of this bug. ***
Changing summary to that of the recent duplicate, to make this bug easier to find.
Summary: wrong selection made in drop-down if page is reloaded or left and returned to → default select option changes on reload (if multiple options have same value)
Please note the behaivour if select is of type "multiple", meaning that several values can be selected: <form> <select size=3 name="test" multiple> <option value="1" selected>FOO</option> <option value="1">FOO</option> <option value="2">BAR</option> </select> </form> If this form is reloaded, two fields will be selected, and not only one, thus "test=1&test=1" will be submitted as form data instead of just "test=1". This could affect the behaviour of a serverside-script. Test-case at http://stock.ter.dk/select.php
Confirmed with 2004032705/Mac. -> All WFM with Mozilla 1.1, reproduced with 1.2.1. regression. But is this a dup of Bug 182157? That testcase has no "selected" attribute...
OS: Windows XP → All
Hardware: PC → All
See http://www.cs.uwaterloo.ca/cscf/teaching/schedule.shtml for another example of why this bug is real, not just a weird edge case "that would never happen". Re: Reloading: it's not completely clear to me that reloading shouldn't restore the default values of the form. Should reloading ever be different from hitting <Enter> in the (unedited) Location bar?
*** Bug 273633 has been marked as a duplicate of this bug. ***
I generally like John's suggestion in comment #6, though I don't think any perfect approach is possible. For example, consider a multiselection box (with several duplicate values) that changes over a reload. If three out of five boxes with value="bad idea" were selected before, what do we want to do if there are now four boxes with value="bad idea" only two of whose indices haven't changed? As a more sensible possibility, consider a select box that the user hasn't touched but whose "selected" element changes over a reload. Surely the web designer's intention is to change the default selected element, right? Is the following restore policy unreasonable? - If a box is "pristine" (untouched by the user), then it has no saved state and should be "restored" by a reset to its default state (as if the new <select> element was being viewed for the very first time). - Otherwise, if the <select> element itself doesn't change over a reload, we guarantee that the selections won't change at all---the same indexes selected before will be reselected after the reload. - Otherwise, we make the following guarantees for special cases: - if the old and new <select> elements aren't "multiple", the selected option will have the same value as before; - if the old and new <select> elements contain no options with duplicate values, the same set of values will be selected as before. - In other cases, we make no special guarantees. Does this cover all the cases discussed so far? An implementation that matches this policy is: if pristine then reset else for each index previously selected if value of this index hasn't changed select that index now store value in set_of_selected_values else store value in set_of_missed_values if set_of_missed_values is nonempty for each option in new <select> element if its value is in set_of_missed_values but not in set_of_selected_values select that option now It's perhaps a little overdesigned, but it seems to handle most cases reasonably. Any comments? By the way, with respect to comment #10 this is definitely a duplicate of bug 182157. Is there a strong preference to mark later bugs duplicates of earlier bugs, or---as here---is it better to keep the integrity of the bug report on which the most work has been done?
*** Bug 321141 has been marked as a duplicate of this bug. ***
Priority: P2 → --
Target Milestone: Future → ---
Assignee: layout.form-controls → nobody
QA Contact: desale → layout.form-controls
Component: Layout: Form Controls → History: Session
QA Contact: layout.form-controls → history.session
This was in the right component, actually. Really, the code in question is content code. But it's certainly not session history code.
Component: History: Session → Layout: Form Controls
QA Contact: history.session → layout.form-controls
I fully agree with #11. The propriety of using duplicate values in a select list is unimportant. Clearly, it happens in the real world and constitutes valid HTML. What should matter is adherence to standards. My understanding of HTML is that it unambiguously specifies that the "selected" property should be used to determine which element(s) are selected, and Firefox correctly implements this on initial page load. Therefore, IMHO, when reloading a form from a server, the user agent should *always* reset the form to the values issued by the server. (i.e. the "selected" property should be the only thing that matters) This is simple and eliminates any possible ambiguity in how to render the page. Regardless of the exact solution, please fix this bug. It's been around for over 9 years.
Severity: major → normal
Component: Layout: Form Controls → DOM: Core & HTML
It seems that restoring the selected options based on the value is quite not a good idea given that we can't guarantee that a given value appears only once. Every other browser seem to pass that testcase so I guess it might be better to pass it too. The only advantage in keeping track of the value is if some pages show the options inside the select in a random order. I would be interested to see how other browsers behave when this happen. Boris, I know you are on vacation but you are clearly the best suited person to look into this patch.
Assignee: nobody → mounir
Status: NEW → ASSIGNED
This patch passes try: https://tbpl.mozilla.org/?tree=Try&rev=58a8efe8547d
Mounir, see comment 6 for why we remember by value...
Comment on attachment 790321 [details] [diff] [review] Patch Removing review request pending response to my question....
You need to log in before you can comment on or make changes to this bug.