Bug 1295543

Summary: Task list: loading animation displayed indefinitely until the mouse is moved
Product: [Retired] JBoss BPMS Platform 6 Reporter: Alessandro Lazarotti <alazarot>
Component: Business CentralAssignee: Neus Miras <nmirasch>
Status: CLOSED DUPLICATE QA Contact: Lukáš Petrovický <lpetrovi>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.2.0CC: alazarot, jhrcek, kverlaen, nmirasch, rrajasek, tradej
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1283503 Environment:
Last Closed: 2016-01-13 17:43:15 UTC Type: Bug
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: 1283503    
Bug Blocks:    

Description Alessandro Lazarotti 2016-01-04 19:29:47 UTC
+++ This bug was initially created as a clone of Bug #1283503 +++

Description of problem:
This is a followup to bug # 1267866
I finally managed to reproduce this issue manually!

The problem is NOT, that LOADING TASK DATA from the backend takes infinite time, but that the LOADING ANIMATION is displayed indefinitely until user moves the mouse. This happens in 30-50% of selenium tests and I was able to consistently reproduce this manually with remote database.

Observe the problem in video attached.
After clicking some tab (i.e. Active) you can see (in the firebug network panel below) that it takes about 0.5 seconds to do backend request to load task information (this is from DB from Boston lab to my laptop in Brno). But even after the request is finished, the loading animation remains to be displayed. To make it disappear I must move the mouse.

Another problem is that for some tabs, the loading animation is not displayed at all. Instead the table remains empty until user moves the mouse (observe this after clicking Group tab in 0:13 in the video)

I'm not sure if this is a blocker (I'll leave the decision to you), because the tasks ARE displayed after user moves the mouse. But from UX perspective this is very annoying and at least it must be documented in release notes.


Version-Release number of selected component (if applicable):
BPM Suite 6.2.0 CR1

How reproducible:
Always with remote DB

Steps to Reproduce:
0. Configure the server to connect to some remote DB (I can provide private info about how to do it using our DB Allocator tool if needed)
1. Create ad-hoc task in task list
2. Click various filter tabs

Actual results:
After some time clicking the tab headers the loading animation is displayed indefinitely - user has to move the mouse to make it disappear.

Expected results:
Loaded tasks should be displayed WITHOUT user having to move the mouse after he clicks the filter tab.

Additional info:
Information to be added to release notes:
When displaying tasks in task list perspective, it might happen (especially when using remote / slow database), that after clicking filter tab (Active, Group, Personal etc.) there is a loading animation displayed indefinitely and no tasks are displayed. The workaround is simply to move the mouse.

--- Additional comment from Jan Hrcek on 2015-11-20 07:40:02 EST ---

Not sure if this will be useful, but we had a similar issue (no data shown until mouse moved) in the past in bz #1265211

--- Additional comment from Neus Miras on 2015-12-21 13:10:08 EST ---

We have added the same solution as the bz commented. Force the execution of the command at the end of the event treatment. 
We have generated two PR
Master
https://github.com/uberfire/uberfire-extensions/pull/155
and
0.7.x
https://github.com/uberfire/uberfire-extensions/pull/154

--- Additional comment from Kris Verlaenen on 2016-01-04 10:09:52 EST ---

Since both PRs were merged, moving this to MODIFIED.

Comment 2 Marco Rietveld 2016-01-08 10:44:20 UTC
Walter, this looks like it might be for you? Otherwise, I think it's for Neus -- please feel free to reassign it to her.

Comment 3 Neus Miras 2016-01-13 17:43:15 UTC

*** This bug has been marked as a duplicate of bug 1283503 ***