Bug 800611 - Use of &#8230 (html horizontal ellipsis) breaks render in some messaging UIs
Summary: Use of &#8230 (html horizontal ellipsis) breaks render in some messaging UIs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: cumin
Version: Development
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: ---
Assignee: grid-maint-list
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-06 19:16 UTC by Trevor McKay
Modified: 2016-05-26 20:06 UTC (History)
5 users (show)

Fixed In Version: cumin-0.1.5492-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-26 20:06:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Trevor McKay 2012-03-06 19:16:17 UTC
Description of problem:

Use of the horizontal ellispis character in html to shorten long values breaks the render of some widgets in Cumin in the Messaging tabs.

Specifically, the fmt_shorten() routine is being used in several places in the messaging tabs to deal with long values.  One of these places is in the render of the form for an "Add binding" task.  If a queue is selected that has a name longer than 40 characters, the shortening code will insert the horizontal ellipsis and break the xml parsing in the browser.

This likely occurs other places, too (search for fmt_shorten).

Version-Release number of selected component (if applicable):


How reproducible:

100%

Steps to Reproduce:
1.  Set up a Cumin instance with Messaging enabled (modify the peronsa: and datas: values in cumin.conf for Messaging.  This is the default in current releases.

2.  Go to the Messsaging->Queues tab and select a queue with a name longer than 40 characters.  Since the machine name is part of the queue name, you can make one exist by creating a really long host name and running the broker from that host.

3.  From the queue drilldown page, click the "Add binding" task
  
Actual results:

Queue names longer than 40 characters will cause an xml parse error.  Queue names shorter than 40 characters will not.

Expected results:

Queue name length should not cause an error.

Additional info:

Here the output of the parse error from an "Add binding" task on a queue.  The name of the machine has been changed for pasting in the BZ, but the length is the same.  Notice the use of #8230 in the last line of the URL.

<sourcetext xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">&lt;input class="disabled" id="modes.QueueBindingAdd_529487120.queue" name="modes.QueueBindingAdd_529487120.queue" value="&lt;span title="qmfc-v2-hb-this-machine-isnt-real-my_fake_inc.com.13376.1"&gt;qmfc-v2-hb-
this-machine-isnt-real-my&amp;#8230;76.1&lt;/span&gt;" tabindex="100" size="30" /&gt;
-----------------------------------------------------------------------------------------------------------------------^</sourcetext>

Comment 1 Chad Roberts 2012-07-25 17:47:25 UTC
For some reason, the value of the form field was being set to a <span> tag, which is not valid XHTML.  My solution was to avoid adding the unnecessary <span> tag when rendering the shortened text in the form field.

Comment 2 Chad Roberts 2012-07-25 17:54:31 UTC
Fixed in revision 5435 on trunk.

Comment 9 Stanislav Graf 2013-04-05 13:52:49 UTC
Reproduced on cumin-0.1.5444-3
Long queue generates:
---
This page contains the following errors:

error on line 35 at column 28: Unescaped '<' not allowed in attributes values
Below is a rendering of the page up to the first error.
---

Tested on cumin-0.1.5675-1
queue - qmfagent-047b2251-db2d-45f5-90e2-826cccafb293
shows in 'Add binding' widget - qmfagent-047b2251-db2d-45f5-90e2-826…b293
The queue name should be properly displayed in the input box.
Submitting binding says:
Add binding: Failed ('ascii' codec can't decode byte 0xe2 in position 36: ordinal not in range(128))
Shouldn't queue name field in 'Add binding' widet be non-editable?

--> ASSIGNED

Comment 10 Anne-Louise Tangring 2016-05-26 20:06:30 UTC
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.


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