2

While answering another question, I encountered something I thought was very odd behavior, and I'm wondering if this should be considered a bug or if it is somewhere in the specification.

This behavior can be observed at this jsFiddle.

Given the following input checkbox element:

<input type="checkbox" id="check" />

If you were to apply the following click event handler (we'll use jQuery here to keep the example concise):

$('#check').on('click', function (e) {
    console.log(this.checked);
    return false; //This prevents the default action from occurring.
});

You'd see in the developer console:

true

What actually happens here is that the checkbox's state is changing before it enters the click event handler. However, if the click event handler prevents the default action, the state of the checkbox is reverted.

This seems like a bug to me. I would expect the checkbox's state to only update after the click event handler, if the default action is not prevented.

Is this a bug? Is this something that should be reported to the different browser distributors?

(I've only tested this in Chrome currently)

crush
  • 16,713
  • 9
  • 59
  • 100
  • @j08691 I didn't see that in my search, thanks. These are basically synonymous questions, though I don't agree with the sentiment expressed in the accepted answer there. While I understand the mechanics underway here, and can imagine a scenario where they could be implemented in the way they are observed, I do not agree that they must be implemented this way. I feel it would be more intuitive for the state to change after all event handlers have been processed. Even with a transactional system, one simply needs to swap the order of evaluation within the transaction. – crush Jan 17 '14 at 21:16

1 Answers1

0

I don't believe that this is a bug, but if you think about it for a second it makes perfect sense as to why the console's output is True

On the initial click of checkbox the value is set to true. It is only set to false AFTER you print to the console via the return false; statement. So no matter how many times you try it, the output will always say True

Adjit
  • 10,134
  • 12
  • 53
  • 98
  • Yes, that is why I said the state is being reverted. I understand why it's being reverted. The mechanic isn't in question. It's more the process that I feel is flawed. In my opinion, the change of state should occur after all click event handlers have been processed. – crush Jan 17 '14 at 21:13
  • @crush But why? The default checkbox action is to set that checkbox to true on click. So that default action takes precedence over your on click action. What this means is that the default action occurs, and then any other on click event handlers for that object are executed. I know you said you understand the mechanics, so if you take a look at this: http://jsfiddle.net/TTAUL/5/ there is a strict order of operations. – Adjit Jan 17 '14 at 21:23
  • You realize we are talking about `performDefaultAction(); if (!performDefaultAction) revertDefaultAction()` vs. `if (!performDefaultAction) return; performDefaultAction();` I'd say either can make sense, but the latter is more intuitive from a user's standpoint. – crush Jan 17 '14 at 21:25
  • @crush Yes I do. http://stackoverflow.com/questions/1357118/event-preventdefault-vs-return-false this might explain it a little better than I can. So really you have to look for something that prevents event bubbling. – Adjit Jan 17 '14 at 21:30
  • I'm not looking for a work around. I'm questioning the ideology of the implementation. The implementation might be working as intended, but it is the intention that I question. I think it would be better if it worked differently. I'll expand upon that in the duplicate question that I overlooked when creating this one. Thanks for your input! – crush Jan 17 '14 at 21:33