Description of problem: Leading and trailing spaces are not trimmed in Add Virtual Disk - Size(GB) Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1.Enter the Add Virtual Disk screen. 2.Enter a size with a leading and trailing. 3. Actual results: The Size(GB) is highlighted in red as an error. Expected results: Leading and trailing spaces should be trimmed. Additional info:
Einav, what's your take on this? This seems like an easy fix if we decide to do it, but I want to make sure this is aligned with the current and future-planned UX overall.
Created attachment 933147 [details] The Size(GB) is highlighted in red as an error
afaik, this problem exists within all input fields using LongEntityModelTextBoxEditor/IntegerEntityModelTextBoxEditor thus making it a ui infra bug
As Tal has mentioned, this problem exists in some other places, too. For example, when adding a VM - try to add a space before the value in "Total Virtual CPUs" under the "System" tab. Moving the bug to UX.
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Cleanest approach is to trim values before they are processed by double/int/long/short parsers (see my patch). This handles well the most common use case when user copy-pastes (or types) some white chars. Using the scenario from bug description: 1. set size with leading/trailing spaces i.e. " 12 " 2. change focus to other field 3. observe that value was replaced with canonical form i.e. "12" Unfortunately there is a side effect -input values that differ only in white chars are now considered equal by the model (see EntityModel#setEntity()).This prevents onChange event: such value will not be replaced in the view(text field) with its canonical form(without white chars). In general this makes sense - input provided by the user is not changed until model will validate it. The simplest steps to re-create: 1. set disk size i.e. "12" 2. change focus to other field - model will be updated with the new value 3. go back to disk size field and add leading spaces i.e. " 12" 4. change focus to other field 5. observe that the value will stay unchanged - according to the model it's the same value so there is no need to re-render If the side effect is not acceptable we could i.e. make model remember old raw value(input from text field) and model value(parsed). Mismatch between old raw value and new raw value could trigger onChange event or even some specialized event.
Created attachment 1662189 [details] behaviour after the fix (with side effect)
it seems related with https://bugzilla.redhat.com/show_bug.cgi?id=1455944
This bug is targeted to 4.4.1 and in modified state. can we re-target to 4.4.0 and move to QA?
(In reply to Sandro Bonazzola from comment #10) > This bug is targeted to 4.4.1 and in modified state. can we re-target to > 4.4.0 and move to QA? yes, done
Verified in ovirt-engine-4.4.0-0.29.master.el8ev.noarch ovirt-engine-webadmin-portal-4.4.0-0.29.master.el8ev.noarch Verified according to steps in to comment 7. Whitespace characters (tried with spaces and tabs) are trimmed after the focus is changed to another field. The mentioned side effect (focusing back and re-adding the whitespaces) does not cause any problem, for example, with a value like (New Virtual Disk) size ' 12 ', the dialog is still successfully submitted and new disk of size 12 (GiB) is created.
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.