Toggling a radio button to false leaves a checked attribute in the DOM

[rjgotten]

Having a Stache binding such as <input type="radio" checked:from="this.checked" />, when the checked view model property toggles from false to true and then back to false it leaves a rogue valueless checked (Chrome) or empty string valued checked="" (Firefox) DOM attribute on the node.

The culprit is in the special handling for checked properties:

can-attribute-observable/behaviors.js

Lines 191 to 212 in a9f5b8a

	checked: {
	get: function(){
	return this.checked;
	},
	set: function(val){
	// - `set( truthy )` => TRUE
	// - `set( "" )` => TRUE
	// - `set()` => TRUE
	// - `set(undefined)` => false.
	var notFalse = !!val || val === "" || arguments.length === 0;
	this.checked = notFalse;
	if(notFalse && this.type === "radio") {
	this.defaultChecked = true;
	}
	},
	remove: function(){
	this.checked = false;
	},
	test: function(){
	return this.nodeName === "INPUT";
	}
	},

Specifically lines 202-204.
As one can see, these only ever flip defaultChecked (which is wired to the presence of the DOM attribute) to true but never flip it back to false.

Should the relevant lines not simply be:

if ( this.type === "radio" ) {
  this.defaultChecked = notFalse;
}

or is there a specific reason, such as workaround for a browser bug, for the current unidirectional behavior?

This is causing headaches for Cypress automated testing for some of our test engineers. The Cypress .should( "be.checked" ) assertion appears at some level to be using presence of the checked DOM attribute, rather than consider the HtmlInputElement.prototype.checked property or use a :checked query selector; and CanJS setting but never unsetting the attribute is messing with it.

[justinbmeyer]

Thanks for reporting, we will look into it.

…

On Mon, Jan 23, 2023 at 9:37 AM rjgotten ***@***.***> wrote: Having a Stache binding such as <input type="radio" checked:from="this.checked" />, when the checked view model property toggles from false to true and then back to false it leaves a rogue valueless checked (Chrome) or empty string valued checked="" (Firefox) DOM attribute on the node. The culprit is in the special handling for checked properties: https://github.com/canjs/can-attribute-observable/blob/a9f5b8a9ef1058a1878bea3d23d84ff9e5c82092/behaviors.js#L191-L212 Specifically lines 202-204. As one can see, these only ever flip defaultChecked (which is wired to the presence of the DOM attribute) to true but *never* flip it back to false. Should the relevant lines not simply be: if ( this.type === "radio" ) { this.defaultChecked = notFalse;} or is there a specific reason, such as workaround for a browser bug, for the current unidirectional behavior? — Reply to this email directly, view it on GitHub <#46>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAATGCSC6RNGGP6JNEIIQ5TWT2QSBANCNFSM6AAAAAAUD7T4MI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>