Page MenuHomePhabricator

Special:CommunityConfiguration: Validation constraints do not always correctly propagate into HTML for numerical inputs
Closed, ResolvedPublicBUG REPORT

Description

When I define a numeric field with a MAXIMUM or MINIMUM, those restrictions are a part of validation, but do not propagate into the HTML. For example, consider the following field (set in CommunityConfigurationExample::ExampleSchema for demonstration purposes):

public const CCExampleNumber = [
	self::TYPE => self::TYPE_INTEGER,
	self::DEFAULT => 0,
	self::MINIMUM => 0,
	self::MAXIMUM => 5,
];

Then, Special:CommunityConfiguration does not allow the user to get over 5 (as expected), but it does allow them to get below 0 (which is not expected). This is shown at the screen recording below:

This appears to happen, because NumberControl.vue uses :min="control.schema.minimum || null" to set the min HTML attribute, and 0 || null evaluates to null in JavaScript.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Urbanecm_WMF changed the subtype of this task from "Task" to "Bug Report".
Urbanecm_WMF moved this task from Inbox to Estimated tasks backlog on the Growth-Team board.
Urbanecm_WMF renamed this task from Special:CommunityConfiguration: Validation for constraints do not always correctly propagate into HTML to Special:CommunityConfiguration: Validation constraints do not always correctly propagate into HTML for numerical inputs.Jun 17 2024, 10:42 AM

Change #1046627 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/CommunityConfiguration@master] fix: correctly treat `0` as a minimum value, not as falsy

https://gerrit.wikimedia.org/r/1046627

Change #1046627 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] fix: correctly treat `0` as a minimum value, not as falsy

https://gerrit.wikimedia.org/r/1046627

@Michael I see two different UI messages for validation upon entering 0 into the form.

Local env with

commit 7d1baeeb77f66c4ac49d0c34a64e7a496ffe699f (HEAD -> master, origin/wmf/branch_cut_pretest, origin/master, origin/HEAD)
Merge: 583bfdc c1e3537
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Mon Jun 17 12:10:47 2024 +0000

    Merge "Editor: filter selection on chip input updates"

commit 583bfdc7707573baeba63cc70cea428cfed3ea4f
Merge: 3e7462a e55b8d4
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Mon Jun 17 11:48:46 2024 +0000

shows

Screen Shot 2024-06-17 at 5.32.59 PM.png (2,424×1,106 px, 186 KB)

cswiki beta shows

Screen Shot 2024-06-17 at 5.33.13 PM.png (1,694×808 px, 127 KB)

The patch - https://gerrit.wikimedia.org/r/1046627 - is successfully merged. Which is the correct validation handing?

@Etonkovidova The behavior cswiki beta is the expected one. It is the browser's native form validation handling (thus looking different on Firefox/Chrome/Safari) and should prevent you from submitting the form.

I'm not sure why you are not seeing that locally as the commit that you have checked out should include my fix.

@Etonkovidova The behavior cswiki beta is the expected one. It is the browser's native form validation handling (thus looking different on Firefox/Chrome/Safari) and should prevent you from submitting the form.

I'm not sure why you are not seeing that locally as the commit that you have checked out should include my fix.

Thx, @Michael Verified testwiki wmf.10:

Chrome 125FF 127
Screen Shot 2024-06-17 at 5.33.13 PM.png (1,694×808 px, 127 KB)
Screen Shot 2024-06-18 at 1.55.11 PM.png (1,582×802 px, 121 KB)