Weird IE Edge issue with onChange prop

So today I discovered that ONLY on the Microsoft Edge, the multiselect’s onChange prop gets called before The parent model’s this.data has been set.

What should happen

this.searchParams Should be set as it is set via the data() call on the parent Vue

data () {
   return {
     searchParams: JSON.parse(JSON.stringify(window.vueData.searchParams))
  }
}

<multiselect :selected.sync="searchParams.tire_width"
                                             :options="options.dropdowns.tire_width.data"                              
                                             :on-change="setMultiselectValue"
                                ></multiselect>

setMultiselectValue is used with the onChange prop. Here is what I get when I console each value.

setMultiselectValue (newVal){
                console.log(this.searchParams); // My whole Search Params object. It has the right structure, but everything has an empty value.... This is not possible as i have not set it anywhere empty.
                console.log(vueData.searchParams); // This is the JSON that gets returned from my backend, and its all full with the data that it should be.
                console.log(newVal); // This is the EXACT value I am expecting, because it is the same as the one in vueData.searchParams. 

How on earth, can Multiselect return its new Value, which is passed by the Selected prop, WHICH is returned from the parent this.searchParams, but at the same time this.searchParams is empty…

I have no idea if I managed to explain this at all, I will happily do some sort of skype call or what ever, because this occurs ONLY on the Edge … Every other browser I could try works flawlessly … And it should…

I cant do a fiddle as this is tightly coupled with my project…

[shentao]

Hmm, I could provide additional events like @close and @open that would return the current value of the multiselect. This would probably very useful when multiple: true as you wouldn’t need to listen to the @update event anymore, but to the @close one. The only drawback being – one would first have to close the dropdown to trigger updates.

With the @open event it would be possible to make better validations, as this would be basically a signal that the dropdown was touched.

Would that be fine?

[shentao]

I believe I’ve tried it, but it has been looking for the native change event, which it, of course, couldn’t find. But I will try it again, to make sure if that was true.