201056 - default select option changes on reload (if multiple options have same value)

Status: NEW

(Core :: DOM: Forms, defect, P3)

Description

[Thomas Winzig]

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).

Comment 1

[Jesiah S]

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>.

Comment 2

[Jesiah S]

D'oh shift reload will force mozilla to forget what the values are on reload

Comment 3

[Thomas Winzig]

OK, it's good to know why, but I think this is still a bug, for the same reasons
given in 166168. While the example used to show the error is extreme, we use
javascript + select boxes for navigation, and there are certain items in these
select boxes that share the same values (normally "section headers" in the
dropdowns).

Shouldn't mozilla remember the index of the selected option, not the value??

Comment 4

[Boris Zbarsky [:bzbarsky]]

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)

Comment 5

[Thomas Winzig]

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?

Comment 6

[John Keiser (jkeiser)]

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.

Comment 7

[Malcolm Rowe]

*** Bug 232312 has been marked as a duplicate of this bug. ***

Comment 8

[Malcolm Rowe]

Changing summary to that of the recent duplicate, to make this bug easier to 
find.

Comment 9

[Peter Brodersen]

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

Comment 10

[HARUNAGA Hirotoshi]

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...

Comment 11

[Isaac Morland]

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?

Comment 12

[HARUNAGA Hirotoshi]

*** Bug 273633 has been marked as a duplicate of this bug. ***

Comment 13

[Kevin Buhr]

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?

Comment 14

[Frank Wein [:mcsmurf]]

*** Bug 321141 has been marked as a duplicate of this bug. ***

Comment 16

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 20

[Boris Zbarsky [:bzbarsky]]

This was in the right component, actually.  Really, the code in question is content code.  But it's certainly not session history code.

Comment 24

[Eric Rasmussen]

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.

Comment 25

[Mounir Lamouri (:mounir)]

Attachment: Patch

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.

Comment 26

[Mounir Lamouri (:mounir)]

This patch passes try: https://tbpl.mozilla.org/?tree=Try&rev=58a8efe8547d

Comment 27

[Boris Zbarsky [:bzbarsky]]

Mounir, see comment 6 for why we remember by value...

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 790321 [details] [diff] [review]
Patch

Removing review request pending response to my question....

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 31

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Still reproducible