|Summary:||Should display the current input digital when no more space to display the whole address in ping page|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||wanghui <huiwa>|
|Component:||ovirt-node||Assignee:||Ryan Barry <rbarry>|
|Status:||CLOSED ERRATA||QA Contact:||Virtualization Bugs <virt-bugs>|
|Version:||3.5.0||CC:||aberezin, bsarathy, cpelland, cshao, ecohen, fdeutsch, gklein, gouyang, hadong, huiwa, iheim, jboggs, leiwang, ovirt-maint, rbalakri, rbarry, yaniwang, ycui|
|Fixed In Version:||ovirt-node-3.0.1-18.el6.7||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-11 20:46:08 UTC||Type:||Bug|
|oVirt Team:||Node||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1065425, 1073056, 1123329, 1142923, 1156165|
Description wanghui 2013-07-04 08:46:06 UTC
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 09:06:22 UTC
And there is also the same issue in all the text box.
Comment 3 wanghui 2013-07-04 09:41:35 UTC
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 13:47:19 UTC
Fabian, you were looking at a way to make text boxes scroll, right?
Comment 5 Fabian Deutsch 2013-07-19 10:09:59 UTC
Yes, I'll be looking into this.
Comment 8 RHEL Product and Program Management 2013-10-14 03:13:09 UTC
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 12:21:32 UTC
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 18:48:56 UTC
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 12:27:15 UTC
(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 13:50:16 UTC
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 05:36:14 UTC
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 08:08:38 UTC
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 22:03:51 UTC
We've got a workaround but then the input fields are not underlined anymore.
Comment 19 Ryan Barry 2014-01-08 22:14:41 UTC
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 08:55:11 UTC
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 15:09:25 UTC
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 14:25:12 UTC
*** Bug 895005 has been marked as a duplicate of this bug. ***
Comment 27 Fabian Deutsch 2014-03-03 17:48:44 UTC
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 18:17:00 UTC
(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 18:43:39 UTC
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 06:58:22 UTC
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 20:46:08 UTC
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