1203668 - changing the value of a select to a value that matches none of the options should put it in a "no option selected" state even when it's a combobox (size=1)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Thiago Henrique]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

Enter in:
http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_select_value
And change this line:
    document.getElementById("mySelect").value = "banana";
with this one:
    document.getElementById("mySelect").value = "banasdana";


Actual results:

The selected value still the first value. 


Expected results:

In:
http://www.w3schools.com/jsref/prop_select_value.asp

Specifies the value of an <option> element in a drop-down list that should get selected. If the value does not exist, the drop-down list will display an empty option

"If the value does not exist, the drop-down list will display an empty option"

I was expecting an empty option and not the first value

Comment 1

[Mats Palmgren (inactive)]

https://html.spec.whatwg.org/multipage/forms.html#the-select-element
"
On setting, the value attribute must set the selectedness of all the option elements
in the list of options to false, and then the first option element in the list of options,
in tree order, whose value is equal to the given new value, if any, must have its
selectedness set to true and its dirtiness set to true.

NOTE: This can result in no element having a selectedness set to true even in the case of
the select element having no multiple attribute and a display size of 1.
"

Other UAs seems to implement it correctly: Chrome, Safari, IE.

Comment 2

[Mats Palmgren (inactive)]

Attachment: part 1

This seems to work locally.

Comment 3

[Mats Palmgren (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1663b0170b03

Comment 4

[Thiago Henrique]

You are fast. tks Mats

Comment 5

[Mats Palmgren (inactive)]

Comment on attachment 8659598 [details] [diff] [review]
part 1

The failures in the Try run looks like it's unrelated.

Source link for more context:
http://mxr.mozilla.org/mozilla-central/source/dom/html/HTMLSelectElement.cpp?rev=e9bb1fc9977a#1189

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8659598 [details] [diff] [review]
part 1

Right now I believe we have the invariant that some option is always selected in a combobox.  There's other code in HTMLSelectElement, and I'm pretty sure in combobox control frame, that depends on that invariant.

Which parts of this code have you audited and why is it ok with the invariant change?  What is the actual UI behavior (e.g. if you click the combobox to see the dropdown, or tab to it and use arrow keys to change the value) that results in this state?

Comment 7

[Mats Palmgren (inactive)]

(In reply to Boris Zbarsky [:bz] from comment #6)
> Right now I believe we have the invariant that some option is always
> selected in a combobox.

I think you're mistaken.  Does this example show that we do NOT have
such an invariant?
data:text/html,<select size=1 onfocus="this.selectedIndex=-1"><option>hello

> There's other code in HTMLSelectElement, and I'm
> pretty sure in combobox control frame, that depends on that invariant.

Can you point out the places you know of, if any?

> Which parts of this code have you audited and why is it ok with the
> invariant change?

None, because I believe we do not have such an invariant (the example
above deselects the option also in FF 3.6, so at least we haven't had
this invariant for a very long time).

> What is the actual UI behavior (e.g. if you click the
> combobox to see the dropdown,

Clicking it shows the dropdown menu as usual, with no option highlighted.
If you move the mouse over the menu it highlights the option under the
mouse as usual.  After moving the mouse outside the menu (without
selecting anything) nothing is highlighted.  Clicking outside the menu
leaves the combobox state as is, i.e. nothing is selected.

> or tab to it and use arrow keys to change the
> value) that results in this state?

Tabbing to it focus it but doesn't change the value.  Using the arrow
keys changes the value as usual, and once you do there is no way to
get back to the unselected state (for the user).  (It *should* be
possible to type ESC to undo the value change and thus unselect
all options again but I think we have an open bug on that somewhere,
possibly bug 307345).

(BTW, I'm testing this on Linux.  Hopefully other platforms behaves
reasonably similar.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Does this example show that we do NOT have such an invariant?

Yes, it does.  I'll assume then that whoever made that unselect all options already made things work correctly in that setup.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8659598 [details] [diff] [review]
part 1

r=me

Comment 10

[Thiago Henrique]

Just another information.
In my case, if you select the first option, the event onchange is not fired.

Comment 11

[Mats Palmgren (inactive)]

Right, that's because the first option is already selected so we do not
detect a change.  That should be fixed now, i.e. going from nothing
selected to something selected should trigger onchange.  Please verify
this in a Nightly build (once the fix shows up there, sometime next week
presumably):  https://nightly.mozilla.org/
(and please let us know if you see any other weirdness)

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/574a93c36fd8

Comment 13

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3de175bd4e83 for a variety pack of mochitest-chrome failures and timeouts, https://treeherder.mozilla.org/logviewer.html#?job_id=13997355&repo=mozilla-inbound

Comment 14

[Phil Ringnalda (:philor)]

And, though nobody wants to get caught in the Gu, https://treeherder.mozilla.org/logviewer.html#?job_id=13997685&repo=mozilla-inbound

Comment 15

[Mats Palmgren (inactive)]

Attachment: part 2 - Fix dependency on this bug in devtools code

This fixes the mochitest failures.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8290703986d0

Comment 16

[Mats Palmgren (inactive)]

Attachment: part3-gaia

This should fix the dependency in this bug in Gaia code, which caused
the "Gu" failures.  I don't know how to submit this patch to Try for
testing though.  Any hints would be appreciated.

Comment 17

[Mats Palmgren (inactive)]

Attachment: part3-gaia

Note: untested since I don't know to submit Gaia patches to Try.

It appears tzSelect() depends on this bug, i.e. setting a bogus value
on a <select> leaves the current value unchanged rather than the new
behavior which is to deselect all options.  I don't know what the
real fix is for this function, but this should emulate the old
<select> behavior I think.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Mats, https://wiki.mozilla.org/ReleaseEngineering/TryServer#Using_a_custom_Gaia has directions for doing a try push with a custom Gaia.  Basically, you need to fork Gaia on github, make your changes, push them to your github fork on some branch, then point try to that changeset as the Gaia to use.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8660357 [details] [diff] [review]
part 2 - Fix dependency on this bug in devtools code

r=me

Comment 21

[Mats Palmgren (inactive)]

It might take quite a while before I have time to spend on this bug again.

Jet, can you perhaps find someone that works on Gaia to reivew+test+land
part 3?  Once that is done we can land part 1 and 2.

Comment 22

[Jet Villegas (inactive)]

Tim: can you help get the "part3-gaia" patch landed per comment 21? Thanks!

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Interesting. Why would the value not actually exist in the <select> list when we construct the list?

This should be another bug to fix (and arguably might not be a bug blocking this fix.)

I'll do that tomorrow (keeping needinfo).

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

As for the patch itself, to keep the old behavior, it make more sense to set selectedIndex to 0 when it's -1 instead of remembering and set the old index?

I don't think -1 and the empty value is ever expected in the rest of the file, so that's probably the safer approach too.

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

... but again, there is a Gu test failure.

Comment 26

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Filed and pull request & try submitted in bug 1218677.

Comment 27

[Mats Palmgren (inactive)]

Comment on attachment 8660359 [details] [diff] [review]
part3-gaia

(this part will land in bug 1218677)

Comment 29

[Joerg Trautmann]

I found a workaround for this problem. 

If you are not sure if the assigned value can be found in the listbox use jquery:

$('#listbox1').val('TestValue');

Using this syntax leads to the correct selectedIndex -1 if the assigned value doesn't match.

Comment 30

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a64dd62f4c12
https://hg.mozilla.org/integration/mozilla-inbound/rev/81df08547187

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a64dd62f4c12
https://hg.mozilla.org/mozilla-central/rev/81df08547187

Comment 32

[Matthew N. [:MattN]]

This is going to break sites (it broke one of mine at https://mnoorenberghe.github.io/bz-dependency-buglist/) so marking site-compat. I thought only Safari had this unusual unselected behaviour but I guess it's the way all browsers are going…

In my case I assumed that if none of the options are selected then the first option would be by default which is no longer true.

Comment 33

[Boris Zbarsky [:bzbarsky]]

> I thought only Safari had this unusual unselected behaviour

Per comment 1, everyone that isn't Firefox did.  So this will only break sites that already didn't work in every other browser...

> In my case I assumed that if none of the options are selected then the first option would be by default

By default, yes.  Testcase:

  data:text/html,<select><option>a<option>b

This bug was about what happens when the page then explicitly sets value to something that matches none of the options.

Comment 34

[Matthew N. [:MattN]]

(In reply to Boris Zbarsky [:bz] from comment #33)
> > I thought only Safari had this unusual unselected behaviour
> 
> Per comment 1, everyone that isn't Firefox did.  So this will only break
> sites that already didn't work in every other browser...

I think this is more recent behaviour for IE (though I code be wrong) and could still break sites with different code for Gecko.

> > In my case I assumed that if none of the options are selected then the first option would be by default
> 
> By default, yes.  Testcase:
> 
>   data:text/html,<select><option>a<option>b
> 
> This bug was about what happens when the page then explicitly sets value to
> something that matches none of the options.

Yeah, sorry, I realized after commenting that this was due to how my code worked and was a step removed from this change but I decided not to comment to reduce spam on the bug.

Comment 35

[Thiago Henrique]

This is not a recent behavior in IE. I have an application with more than 10 years that works in IE with this behavior.

Comment 36

[Kohei Yoshino]

Just posted the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/select-value-is-now-properly-updated-when-non-existent-option-is-programmatically-selected/

Comment 37

[Jean-Yves Perrier [:teoli]]

Added an entry in:
https://developer.mozilla.org/en-US/Firefox/Releases/46#DOM_HTML_DOM