Bug 981189 - Should display the current input digital when no more space to display the whole address in ping page
Should display the current input digital when no more space to display the wh...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node (Show other bugs)
3.5.0
Unspecified Unspecified
urgent Severity urgent
: ---
: 3.5.0
Assigned To: Ryan Barry
Virtualization Bugs
node
: ZStream
: 895005 (view as bug list)
Depends On:
Blocks: 1065425 1073056 1123329 rhev3.5beta 1156165
  Show dependency treegraph
 
Reported: 2013-07-04 04:46 EDT by wanghui
Modified: 2016-02-10 15:02 EST (History)
18 users (show)

See Also:
Fixed In Version: ovirt-node-3.0.1-18.el6.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-11 15:46:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Node
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ping page display (24.75 KB, image/png)
2013-07-04 04:46 EDT, wanghui
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 25044 None None None Never

  None (edit)
Description wanghui 2013-07-04 04:46:06 EDT
Created attachment 768649 [details]
ping page display

Description of problem:
In the ping page, it should display the current input digital when there is no more space to display the whole address.

Version-Release number of selected component (if applicable):
rhev-hypervisor6-6.5-20130222.0.auto1707.el6.iso
ovirt-node-3.0.0-1.999.20130701111251git99aadc6.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Clean install the rhev-hypervisor6-6.5.
2. Configure the network with ipv6 auto mode.
3. Input the ipv6 address which you want to ping in ping page.
   Ping a remote host
   Address: 3ef1:b8:1:0:5054:ff:fe26:2052

Actual results:
In step3, when you input the last 3 digital, you can see whether you input it or not because it can not display.

Expected results:
In step3, you can see the digital which you currently input.

Additional info:
Comment 2 wanghui 2013-07-04 05:06:22 EDT
And there is also the same issue in all the text box.
Comment 3 wanghui 2013-07-04 05:41:35 EDT
It should be better to reorganize the length of all the text box especially those related to ipv6 address. Cause in ipv6, it will need more space to display it.
Comment 4 Mike Burns 2013-07-08 09:47:19 EDT
Fabian,  you were looking at a way to make text boxes scroll, right?
Comment 5 Fabian Deutsch 2013-07-19 06:09:59 EDT
Yes, I'll be looking into this.
Comment 8 RHEL Product and Program Management 2013-10-13 23:13:09 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 Fabian Deutsch 2013-11-14 07:21:32 EST
Ryan,

can you take a look at this.
It would probably help for 6.5 if the entry always shows the content around the cursor - and this is currently not happening.
I wonder if this is a urwid problem or if we miss to set some falgs when building the UI.
Comment 11 Ryan Barry 2013-11-14 13:48:56 EST
There doesn't seem to be an easy way to do this in urwid, so I changed the render method for EditWithChars to be smarter when the length of the input is longer than the length of the field. 

On the plus side, we can see characters which are being typed.

On the downside, I haven't found a way to decouple urwid's cursor position and from urwid.Edit.edit_pos -- trying to make it behave like a normal text box which can be scrolled from side to side with arrow keys with a cursor position which is meaningful. Setting the cursor position necessarily updates edit_pos.

While this patch resolves the current problem, it doesn't solve the long-term problem of making the Entry field, but that may be doable for 6.6
Comment 12 Fabian Deutsch 2013-12-11 07:27:15 EST
(In reply to Ryan Barry from comment #11)
> There doesn't seem to be an easy way to do this in urwid, so I changed the
> render method for EditWithChars to be smarter when the length of the input
> is longer than the length of the field. 
> 
> On the plus side, we can see characters which are being typed.
> 
> On the downside, I haven't found a way to decouple urwid's cursor position
> and from urwid.Edit.edit_pos -- trying to make it behave like a normal text
> box which can be scrolled from side to side with arrow keys with a cursor
> position which is meaningful. Setting the cursor position necessarily
> updates edit_pos.
> 
> While this patch resolves the current problem, it doesn't solve the
> long-term problem of making the Entry field, but that may be doable for 6.6

Yep. We should definetly target scrolling within the Entry field for 6.6. We can possibly achieve this by inheriting more from the original Entry class.
Comment 13 Ryan Barry 2013-12-11 08:50:16 EST
The original urwid entry class doesn't appear to support this either. It adds an additional line for entry below for overflow text, but I haven't experimented with it much.
Comment 15 Cheryn Tan 2014-01-08 00:36:14 EST
This bug is currently attached to errata RHBA-2013:15277. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:
https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes

Thank you for your help.
Comment 17 wanghui 2014-01-08 03:08:38 EST
According to comment#16, this issue is not fixed completely, so change the status from ON_QA to ASSINED.
Comment 18 Fabian Deutsch 2014-01-08 17:03:51 EST
We've got a workaround but then the input fields are not underlined anymore.
Comment 19 Ryan Barry 2014-01-08 17:14:41 EST
If I'm lucky, I'll get a chance to look at this tomorrow, but it may not be feasible to correct during this development cycle (if it's too complex or simply takes too much time with the other issues and a short deadline).

If it can't be resolved, and the choices are either:

input fields are no longer underlined (potentially with a different background color to emphasize that they're editable)
input fields cannot be scrolled to the left without deleting characters

Which would be preferable?
Comment 23 Fabian Deutsch 2014-02-18 03:55:11 EST
The following snippet can probably help to solve this for all underlined fields:

https://gist.github.com/wardi/8337153
Comment 24 Ryan Barry 2014-02-18 10:09:25 EST
I'll experiment with that snippet, though it currently has the same problem as comment #13 -- adding additional rows is problematic.
Comment 25 Fabian Deutsch 2014-02-21 09:25:12 EST
*** Bug 895005 has been marked as a duplicate of this bug. ***
Comment 27 Fabian Deutsch 2014-03-03 12:48:44 EST
Basic functionality is working, but exception when you press <END> in a text field where the contents are exceeding the length of the widget.
Comment 28 Ryan Barry 2014-03-03 13:17:00 EST
(In reply to Fabian Deutsch from comment #27)
> Basic functionality is working, but exception when you press <END> in a text
> field where the contents are exceeding the length of the widget.

This strongly appears to be a bug in urwid, but I'll investigate.
Comment 29 Ryan Barry 2014-03-03 13:43:39 EST
Patch updated, though I have no idea why urwid has that particular assertion, since no other problems come up if it's removed.
Comment 36 wanghui 2014-12-18 01:58:22 EST
Test version:
rhev-hypervisor6-6.6-20141212.0.iso
ovirt-node-3.1.0-0.34.20141210git0c9c493.el6.noarch

Test steps:
1. Clean install rhev-hypervisor6-6.6-20141212.0.iso.
2. Input long character in text field such as Hostname, DNS server, RHN Registration page.

Test result:
1. During input long character, it shows the current input character.
2. After save the configuration, it shows the long character starts at the first one. And the curse can be moved to the end to modify it. 

So this issue is fixed in rhev-hypervisor6-6.6-20141212.0.iso. Change the status from ON_QA to Verified.
Comment 38 errata-xmlrpc 2015-02-11 15:46:08 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0160.html

Note You need to log in before you can comment on or make changes to this bug.