Bug 589199 - modal view of "Synchronization Results History" entries disappears after few seconds
Summary: modal view of "Synchronization Results History" entries disappears after few ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Content
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks: jon24-content
TreeView+ depends on / blocked
 
Reported: 2010-05-05 15:40 UTC by Simeon Pinder
Modified: 2010-08-12 16:45 UTC (History)
0 users

Fixed In Version: 2.4
Clone Of:
Environment:
Last Closed: 2010-08-12 16:45:39 UTC
Embargoed:


Attachments (Terms of Use)
modal success message (114.67 KB, image/jpeg)
2010-05-05 15:40 UTC, Simeon Pinder
no flags Details

Description Simeon Pinder 2010-05-05 15:40:43 UTC
Created attachment 411653 [details]
modal success message

Description of problem:
Modal result view of a Successful Synchronization run stays visible for a few seconds and then disappears.  For synchronization results of more than a few lines, it will be hard for user to read and act on.  See attached results for synchronization run image before it disappeared. 

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

Jon build 127 from http://hudson-qe.rhq.rdu.redhat.com:8080/job/jon/
should map to master build 280.


How reproducible:
Every time.

Steps to Reproduce:
1. Install JON 
2. Update the CSP credentials for "JBoss CSP Patch Feed" content source.
3. Initiate synchronization results. Select a successful synchronization run and click on it.  Modal view of the synchronization results disappears.
  
Actual results:
Modal view is visible for 3-5 seconds then vanishes.

Expected results:
Modal results view should remain until user closes box or much longer timeout occurs. 

Additional info:
It does not matter if the user is browsing the modal window or still using it. After a few seconds results disappear.

Possibly related to BZ 589161.

Comment 1 Simeon Pinder 2010-05-12 23:22:42 UTC
After much research, this is not related to 589161 at all. 

The problem:
The modal panel is implemented as a child element of an ajax region that is updated every 7 seconds.  This means than every few seconds the modal panel is reset even if the user is still viewing it. 

The fix:
After consult with Joseph, the suggested fix is to pull the modalPanel's definition outside of the polled Ajax region and simply attach it later to avoid recursive update with the other polling region elements.  The extraction of the modal element is not difficult but passing the iteration content to the modal panel proved remarkably difficult.  None of the parameter passing to the rich:modalPanel techniques I found appear to work.  Other mechanisms of rhq implementations of retrieving data to populate the modal panels do not appear to work for this specific situation.  See /rhq/common/events/history.xhtml for more details.  In each rhq case I found the data populating the modal panel was not table-iteration sensitive and could be linked back to an explicit user checkbox selection so that other utilities could be used to retrieve the correct information. 

This is likely a richfaces bug, but the documentation for the functionality only describes passing javascript entities to the modal entities and not full EL java objects.  Unable to find a fix for this I explicitly identified all of the other ajax regions needing re-rendering(except the modal one) and iterated these regions in the polling thread to be re-rendered. Not efficient but effective. This should be improved upon if we can find the correct mechanism to parameter pass to the modalPanels.

Current fix is available in successful master build >= 298 with 
commit 96e557c5b3aafc76738124874075b4eeb93d7de0

Comment 2 Corey Welton 2010-05-19 14:02:07 UTC
QA Verified, the modal window no longer disappears,

Comment 3 Corey Welton 2010-08-12 16:45:39 UTC
Mass-closure of verified bugs against JON.


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