Bug 589199

Summary: modal view of "Synchronization Results History" entries disappears after few seconds
Product: [Other] RHQ Project Reporter: Simeon Pinder <spinder>
Component: ContentAssignee: Simeon Pinder <spinder>
Status: CLOSED CURRENTRELEASE QA Contact: Corey Welton <cwelton>
Severity: medium Docs Contact:
Priority: low    
Version: unspecified   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-12 16:45:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 586123    
Attachments:
Description Flags
modal success message none

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.