Checkbox doesn't have it's checked state set via v-model if the click event is prevented

[danielsamuels]

Version

2.6.6

Reproduction link

https://jsfiddle.net/s4ub8dnc/3/

Steps to reproduce

I have a checkbox which needs to get it's checked state from a VueX store, but I also need to be able to determine whether or not shift was being held when the checkbox was clicked. To do this I'm using @click.prevent on the checkbox (so that I have the event being passed to the method) and then using v-model to determine the checked state.

However, regardless of whether or not the v-model value is true or false, the checkbox never gains the checked state if the click is prevented. It seems that there is still a reliance on the click event in order to set the state.

What is expected?

I would expect the checkbox to be checked if the v-model value is set to true, regardless of how the checkbox arrived at that state - by something else setting it to true, or by the click handler setting it.

What is actually happening?

The click binding having .prevent on it stops the checkbox from receiving it's checked state, even when the v-model value is true

---

The reason why I haven't just used a setter in the computed is because the setter doesn't get given the click event, so I can determine whether or not shift was being held at the point of clicking the checkbox.

[LinusBorg]

Works with 2.5.22, likely related to nextTick changes in 2.6 ...

However your example works fine without the .prevent, and I don't understand why you added it in the first place?

[posva]

I think this is working as expected but the scenario and browser behaviour is weird and makes it complicated: you are preventing the checkbox to get checked but still setting the state on the same function, it's like saying to the browser not to tick the checkbox at the same time you change the state that is supposed to control that checkbox: it doesn't make any sense.
Adding a delay of 0ms before setting the state works around the problem and I think that given the case, it's good enough. What is even the use case for this? If you want to control whether it's possible to check the checkbox or not, you are better off preventing default inside of the handler only when you don't want to set the checked state

[LinusBorg]

I think you are right, @posva.

And OPs original code only worked in 2.5 because the DOM update happened in a macrotask, so the prevent had "lost" it's effect already as the event was over.

But it wasn't necessary in 2.5 and isn't necessary now, so we might even say OPs code only accidentally worked before and the"workaround" for 2.6 is the correct implementation.

But I'll wait for OPs feedback before closing this, but remove the bug label for now.

[yyx990803]

I'd say this is a wontfix since the usage doesn't really make much sense... preventing the click event has the side effect of preventing the checkbox from being checked, and the fact that it worked in 2.5 was just an accident. This was never meant to work.

There's definitely some way to achieve what you want without having to do this, and it would be helpful if there's more information on why you are doing this in the first place.

[danielsamuels]

My usecase is quite straightforward feature-wise, imagine a table of data where every row has a checkbox on the left which shows you to select the row, allowing you to perform an action on all selected rows. Now imagine you have 5 rows, you select the first row, hold shift and then select the 5th row. In this scenario I want all of the intermediary rows to also be selected (standard range select). The state for which rows are selected is stored on the table, so we emit a selected event from the row component.

If we were to use v-model to emit the event we wouldn't have any way to determine whether or not shift was being held at the point of clicking the checkbox, so instead we have to use @click to capture the click event and use e.shiftPressed to determine the shift state. If you're using v-model to set the selected state (as one should), then this entire process breaks down because of the reported issue.

If you've got another way to achieve this, I'd be open to suggestions, but it seems like most solutions would involve manually seeing .checked on the element or something similar. For what it's worth I ended up removing the prevent and no-opping the computed setter (otherwise Vue raises an exception).

[yyx990803]

Then in this case you probably shouldn't be using v-model at all?

[linnea]

My team is also having this issue, we have a component library with a checkbox component. One of our developer's use cases is this:

https://jsfiddle.net/linnea/uhm8a2b7/5/

They need to check some permission or prompt a confirmation before changing the value of the checkbox. The value changes to true, but the checkbox doesn't actually appear checked

The setTimeout workaround works, but that means they'll have to update all @click.prevents on their checkboxes with this workaround before updating.

[flozero]

https://jsfiddle.net/rwe2t04h/8/

I used setTimeout that will be execute right after all micros task will be execute.

Work for me. I think it's because of the window.confirm that is a browser script and it execute immediately so i think the dom refresh update time is before the window.confirm that's weird to me. I think something missing here

[danielsamuels]

Then in this case you probably shouldn't be using v-model at all?

As far as I'm aware there's no other documented method of setting the checked state other than v-model. I'd prefer not to set .checked manually (perhaps in a watcher) as that feels like it goes against the point of having Vue manage the DOM state. Given that the workaround is simply to nextTick the setting of the value, this does feel like more of a bug.

I'd be interested to see what your approach would be to achieve the aims in my use-case outlined above.

[danielsamuels]

Just to address some other points which were edited into earlier comments:

However your example works fine without the .prevent, and I don't understand why you added it in the first place?

If you remove the .prevent you get an exception out of the computed as you're trying to set the value without the computed having a setter. I don't consider exceptions being raised to be acceptable in a production environment even if it does appear to work.

you are preventing the checkbox to get checked but still setting the state on the same function, it's like saying to the browser not to tick the checkbox at the same time you change the state that is supposed to control that checkbox: it doesn't make any sense.

The problem with this argument is that if you implement the exact same behaviour in pure JS, it works: https://jsfiddle.net/u5neLz4w/4/

So if I didn't use Vue to do the exact same thing, the functionality would work. But because v-model isn't working correctly - and I do believe that to be the case - the checkbox doesn't get it's state set correctly, even if the underlying value is correct.