Ember.Select auto-selects the last <option> by default in Firefox Browser

[grapho]

Just as the title suggests: I have noticed that in Ember Version 1.11.1, Ember.Select is a little unexpected behavior when in Firefox Browser.

The following jsbin (using Ember Version 1.11.3) shows Ember.Select(s) alongside a native HTML <select>.

http://emberjs.jsbin.com/cuwoci/1/edit?html,js,output

You should see that by default, the Firefox browser is auto-selecting the last <option> in the select list, as opposed to the first option like a native select.

It is hard to tell if this can be an Ember fix, or if firefox is interpreting the ember.select in a strange way and there is no direct way to fix?

Other browsers seem to be fine, and i did not notice this issue in previous releases (1.8 or 1.9.1).

[mixonic]

On a phone right now and digging up a link is difficult, but this is a known regression. It appears to be a WebKit bug that makes the first item selected, and other browsers are correct oddly enough.

We've been pushing on Glimmer and unable to find the time for a fix on this. Look to the tildeio/htmlbars and krisseldon/morph-range repos for more details.

[grapho]

@mixonic thanks for the reply. I will see if i can contribute to a solution, but in the meantime I will make sure to not rely so much on the "default" selection in my workings. I did not realize this was a known issue until now.

[rwjblue]

This came up shortly after 1.11.0 was released, but we haven't had time to find a solution just yet.

@grapho - Sorry this is causing you pain.

[grapho]

@rwjblue haha, no worries, i can get my app to behave the way i want ;)

@mixonic based on your comment above... what is the expected default selection supposed to be according to HTML spec.. the first <option>? or the last <option>? i was not 100% clear on that.

anyway though, do you know where I can find the definition of the select view? maybe i can spend a little time looking at it?

I'm looking at the code again... The initial observation is that if there is no "prompt" property defined, and either "value" or "selection" is bound to a null value (or not bound at all), the SelectView relies on _changeSingle() to the set object at the index that is returned from this.$()[0].selectedIndex which i have confirmed returns either 0 from some browsers or the "last" index on other browsers. I dont see a clean way around that, except for explicitly setting "selection" property to the first object in the array on('didInsertElement')... perhaps as part of the _setDefaults() method and then letting the rest of the code operate as normal after that.

I will play around with it and see if i can get something to work.

[grapho]

@mixonic @rwjblue, sorry to be a pain, but in your opinion(s) is this an issue in the Ember.Select view itself? or is it more an issue of Ember rendering the <options> in a way that is confusing the browsers selectedIndex properties?

If you think it is indeed the Ember.Select, I have a possible PR ready.

[rwjblue]

I believe that the issue is ultimately with HTMLBars combined with our usage in Ember.Select, but @mixonic likely understands the underlying problem better than I. We might be able to correct the issue as a work around in Ember itself (by selecting the first option when no default selection is setup).

[grapho]

@rwjblue my PR (currently a fork) would do that in the Ember.Select _setDefaults() method... since it only is an issue if the is no "prompt", and the default "selection" or "value" binding is nul, AND only if it is a single style select.

So, yes it is a workaround, for perhaps a less-than-common situation... but i will hold off on the PR if @mixonic feels there is a deeper fix to the issue.

[rwjblue]

@grapho - Please feel free to PR, would likely be easier for @mixonic to review both at the same time.

[grapho]

k

#10997

[mixonic]

IMO this is a subtle browser bug in Chrome. I would like to have a repro to open an issue with, then patch it ourselves at a level lower than Ember.Select

[grapho]

@mixonic fair enough. what steps could i take to set that path in motion?

Would this original ember jsbin be a sufficient reproduction of the issue?

http://emberjs.jsbin.com/cuwoci/2/edit

[raytiley]

This just bit me. Unlike the original fiddle I'm specifying a prompt so that option should be selected, not the last option. Works fine in chrome... broken in IE / Firefox.

{{view 'select'
  prompt='--Filter by--' 
  content=fieldOptions
  optionValuePath='content.field'
  optionLabelPath='content.display'
  value=group.filters.firstObject.field}}

Anyone have a workaround?

[ericop]

Yeah, this is a major bummer! We use Select2 on Ember Selects to bling them out in our app, and the placeholder/prompt doesn't work in Firefox. We have to do this in one case to add icons and auto-complete functionality for our users.

If we use a Select2 component straight away (not adding the Select to the DOM via a vanilla Ember Select as mention in the first scenario) then we don't run into this problem. For most traditional cases you should be all set using this (code below, hope it helps).

App.Select2View = Ember.Select.extend
  onChange:   undefined
  classNames: ['my-select-2']

  change: (e) ->
    @_super(e)
    if @onChange?
      @get('controller')?.send(@onChange, @get('selection'))

  valueObserver: (->
    if @changingFrom isnt @get('value')
      Em.run.scheduleOnce('afterRender', this, '_notifyValueChange')
    @changingFrom = @get('value')
  ).observesBefore('value')

  afterRenderEvent: ->
    @$().select2()

  _notifyValueChange: ->
    @$()?.val(@get('value')).trigger('change')

{{view "select2" content=shifts multiple=true optionLabelPath="content.title" closeOnSelect=false selection=selection}}

[mixonic]

/cc @krisselden as well