Bug 1135786

Summary: [RFE] trim spaces in integer fields
Product: [oVirt] ovirt-engine Reporter: lkuchlan <lkuchlan>
Component: Frontend.WebAdminAssignee: rszwajko
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Novotny <pnovotny>
Severity: low Docs Contact:
Priority: low    
Version: ---CC: bugs, gshereme, lleistne, lwright, mgoldboi, michal.skrivanek, rszwajko, sgratch, srevivo, tnisan
Target Milestone: ovirt-4.4.0Keywords: FutureFeature, Improvement, UserExperience
Target Release: ---Flags: michal.skrivanek: ovirt-4.4?
ylavi: planning_ack?
pm-rhel: devel_ack+
lleistne: testing_ack+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-20 20:01:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: UX RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The Size(GB) is highlighted in red as an error
none
behaviour after the fix (with side effect) none

Description lkuchlan 2014-08-31 14:24:02 UTC 
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:
Comment 1 Allon Mureinik 2014-08-31 14:29:51 UTC 
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.
Comment 2 lkuchlan 2014-08-31 14:29:56 UTC 
Created attachment 933147 [details]
The Size(GB) is highlighted in red as an error
Comment 3 Tal Nisan 2014-08-31 14:37:19 UTC 
afaik, this problem exists within all input fields using LongEntityModelTextBoxEditor/IntegerEntityModelTextBoxEditor thus making it a ui infra bug
Comment 4 Idan Shaby 2014-09-10 13:59:39 UTC 
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.
Comment 5 Red Hat Bugzilla Rules Engine 2017-11-30 17:31:00 UTC 
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 ?.
Comment 6 Sandro Bonazzola 2019-01-28 09:40:33 UTC 
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.
Comment 7 rszwajko 2020-02-06 13:49:11 UTC 
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.
Comment 8 rszwajko 2020-02-10 15:53:47 UTC 
Created attachment 1662189 [details]
behaviour after the fix (with side effect)
Comment 9 rszwajko 2020-02-21 16:53:36 UTC 
it seems related with https://bugzilla.redhat.com/show_bug.cgi?id=1455944
Comment 10 Sandro Bonazzola 2020-03-20 15:12:21 UTC 
This bug is targeted to 4.4.1 and in modified state. can we re-target to 4.4.0 and move to QA?
Comment 11 Sharon Gratch 2020-03-25 18:00:37 UTC 
(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
Comment 12 Pavel Novotny 2020-03-31 21:29:11 UTC 
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.
Comment 13 Sandro Bonazzola 2020-05-20 20:01:00 UTC 
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.