v-model on custom component behaves differently in IE and Edge

[andrewcourtice]

Vue Version

2.1.10

Issue Description

Based on other examples I've seen, when embedding a checkbox in a custom component a 'proxy' value has to be used to emulate the native v-model behaviour for a checkbox or radio input.

This is particularly important when binding v-model on the custom component to an array as opposed to a boolean.

This technique works fine in Firefox and Webkit-based browsers but fails in IE and Edge.

Demonstration of Issue

http://jsfiddle.net/andrewcourtice/jgxzbbvv/

Steps to Reproduce

1. Open the above fiddle in a Firefox or a Webkit-based browser
2. Check the checkboxes and note the array of selected items being updated correctly
3. Open the above fiddle in IE or Edge
4. Check the checkboxes and note the difference in behaviour to step 2

Expected Outcome

The array of selected items (and the raw output) should be updated as each item is checked.

Actual Outcome

In IE and Edge the raw output is displaying a boolean value and the checked state of the checkboxes is inconsistent.

Thanks!

[denistsoi]

Added IE-Edge (VirtualBox running Edge Windows 10)
screencap for reference; (no errors are popping up on the console either).

Edit: (noticing how clicking john returns false)
Extremely odd behaviour;

[sqal]

It's worth pointing out this worked fine in Vue <= 2.1.8

[sunnyone]

+1

[denistsoi]

@sunnyone, @Thijs5 - and for anyone else; don't populate the issue feed with +1; it's unhelpful and clearly, you need to use the "ADD REACTION" button if you want to drive attention to an issue.

[posva]

Hey, sorry for the delay. Completely forgot about this.
This happens because the onChange fires before the computed setter in Edge. If you're using a computed setter, you don't need an onChange event handler, you should simply emit in the setter:

http://jsfiddle.net/bsy8ss2L/

[jdalton]

@posva Could you provide a bit more info on the "onChange fires before the computed setter in Edge". How is the computed setter fired? I'm trying to get enough info for an Edge bug report.

[yyx990803]

@jdalton AFAIK, the problem is that when clicking on the checkbox, the order of the click and change events being fired is different in IE/Edge than that in other browsers:

https://jsfiddle.net/rj3g9j0y/

Chrome/FF: click -> change
IE/Edge/Safari: change -> click

I'm not sure if this behavior is specified anywhere in the spec though.

[jdalton]

Ah nice! Thanks for the simplified repro!

[posva]

I'm trying to get enough info for an Edge bug report

@jdalton awesome!

@yyx990803 BTW, should we close this since it's related to the browser firing in a different order?

[jdalton]

I've reported the issue internally. I'll ping back when I get more info.

[yyx990803]

@jdalton update: it seems PhantomJS and Safari also fire change before click.

The spec states that:

Default actions are usually performed after the event dispatch has been completed, but in exceptional cases they may also be performed immediately before the event is dispatched.

So technically, change doesn't have to be fired after click. However, imo it really should because logically, change is a result of the default action for click. For example, if I do event.preventDefault() inside a click listener on a checkbox, it should be able to prevent the change event from happening altogether (this is the current behavior in Chrome/FF, but not in Safari/IE/Edge/PhantomJS).

[jdalton]

Oh ya, not arguing for the current behavior. I think Edge should align with Chrome/FF.