This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27414 - Activation of <input> when mutability or type is changed
Summary: Activation of <input> when mutability or type is changed
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-24 02:33 UTC by Manish Goregaokar
Modified: 2017-07-21 14:49 UTC (History)
3 users (show)

See Also:


Attachments

Description Manish Goregaokar 2014-11-24 02:33:45 UTC
https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-%28type=radio%29 

> If the element R is mutable, then: The pre-click activation steps for R consist of getting a reference to the element in R's radio button group that has its checkedness set to true, if any, and then setting R's checkedness to true. The canceled activation steps for R consist of checking if the element to which a reference was obtained in the pre-click activation steps, if any, is still in what is now R's radio button group, if it still has one, and if so, setting that element's checkedness to true; or else, if there was no such element, or that element is no longer in R's radio button group, or if R no longer has a radio button group, setting R's checkedness to false. The activation behavior for R is to fire a simple event that bubbles named input at R and then fire a simple event that bubbles named change at R.
 
(Applies to activation of other types too)

How do we handle the type or mutability being changed by handlers on the click event fired by activation
   - In the context of the canceled activation
   - In the context of activation behavior (post-click activation) 

Should we declare that all bets are off and do nothing? Or should we still try to restore state somehow?

A quick test in Firefox for a checkbox with a click handler that toggles its type with radiobutton gives strange results:

 1. If the checkbox is checked, you will toggle between a checked checkbox and unselected radiobutton
 2. If the checkbox is not checked, it will go from unchecked checkbox  -> checked radio -> checked checkbox -> (same as 1)

With these results I'm not exactly sure how to handle the change in types.

In case I have the same handler except that it calls event.defaultPrevented(), the canceled activation seems to reset to the old state (eg clicking a checkbox will give a radio button of the same checkedness and vice versa)

Having a handler that disables the checkbox:

 - Will give a disabled checkbox of opposite checkedness in case preventDefault() is not called
 - Will give a disabled checkbox of the same checkedness in case preventDefault() is not called.

It seems pretty clear that a change of mutability within the handler should not stop the canceled activation/post event activation (though the spec seems to say otherwise)

Should the behavior be specced (seems like a far edge case to me)? If so, what should it be?
Comment 1 Ian 'Hixie' Hickson 2014-11-24 19:02:02 UTC
The current text is intended to be exactly precise with respect to handling these cases. Not all browsers exactly agree on the behaviour, but the specced behaviour is what seemed the most sensible given the compatibility constraints.
Comment 2 Manish Goregaokar 2014-11-25 00:26:31 UTC
I'm not entirely certain what the current spec is saying though.

Is it saying that in case the type or mutability changes, just go ahead and try to restore state with the new canceled/post activation handler?
Comment 3 Ian 'Hixie' Hickson 2014-11-25 07:20:13 UTC
Just apply the current text literally as written. Do you have a concrete case you would like me to walk through to explain what it says?
Comment 4 Manish Goregaokar 2014-11-25 13:07:27 UTC
 - User clicks radio button in group of three radio buttons
 - Onclick handler first changes the type to a checkbox, then calls preventDefault()
 - Now do I run the canceled activation steps for a checkbox, or for the old radio button? The former seems to align with the spec. The latter seems to make more sense.


Similarly, if an element is made immutable in the click handler, should preventDefault() undo the activation?
Comment 5 Ian 'Hixie' Hickson 2014-11-26 19:35:15 UTC
Ah, yeah, the question of _which_ canceled activation steps to run is an interesting one, I should definitely make that clearer (it's supposed to be the ones that match the activation steps, as in, you take a reference to all the steps at the top, then run them all as appropriate).
Comment 6 Manish Goregaokar 2014-11-27 06:19:54 UTC
"All the steps at the top"?

Still confusing :P
Comment 7 Ian 'Hixie' Hickson 2014-11-28 04:24:47 UTC
At the top of the algorithm that calls all these internal callbacks.
Comment 8 Manish Goregaokar 2014-11-28 04:29:31 UTC
Ah, okay. So if the type changes, we continue with the "old" canceled activation steps.


Seems okay. I'd prefer just abandoning ship for such cases (it needlessly makes the implementation more complicated), though.
Comment 9 Ian 'Hixie' Hickson 2014-12-01 18:53:01 UTC
This is just describing (or trying to describe, given that it isn't clear and I need to fix that!) what browsers do. We're unfortunately many years past being able to design a good API here. :-(
Comment 10 Anne 2017-07-21 14:49:10 UTC
(This should be even clearer now that some of this moved into DOM.)