Bug 1267901 - Project Explorer sometimes empty after switching to Authoring perspective
Project Explorer sometimes empty after switching to Authoring perspective
Status: ASSIGNED
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.2.0
Unspecified Unspecified
medium Severity low
: ER4
: 6.2.0
Assigned To: manstis
Jiri Locker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-01 07:00 EDT by Jiri Locker
Modified: 2016-07-31 21:11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Empty Project Explorer (82.21 KB, image/png)
2015-10-01 07:02 EDT, Jiri Locker
no flags Details
Empty Project Explorer (with Firebug inspection) (188.24 KB, image/png)
2015-10-01 07:02 EDT, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2015-10-01 07:00:58 EDT
Description of problem:
Sometimes after logging in to business central and switching to authoring perspective, Project Explorer displays no content. When reproducing manually it is possible to fix the condition by moving vertical splitbar (changing project explorer width) but this workaround not always works in automated tests.

The chance to reproduce manually is low (approx. 1 in 20 attempts) but I recommend to try immediately after starting business central with some non-trivial repositories.

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

How reproducible:
difficult

Steps to Reproduce:
1. Start business central.
2. Log in, switch to authoring perspective
3. [repeat] Switch to home perspective and back to authoring

Actual results:
Sometimes Project Explorer remains empty.

Expected results:
Project Explorer should never be empty.

Additional info:
Comment 1 Jiri Locker 2015-10-01 07:02 EDT
Created attachment 1079032 [details]
Empty Project Explorer
Comment 2 Jiri Locker 2015-10-01 07:02 EDT
Created attachment 1079033 [details]
Empty Project Explorer (with Firebug inspection)
Comment 3 Jiri Locker 2015-10-01 07:04:29 EDT
Screenshot with Firebug inspection illustrates that some HTML content is present but hidden.
Comment 4 manstis 2015-10-01 10:45:21 EDT
Hi Jiri,

Do you recall if Project Explorer was in "Business View" or "Technical View" and whether you had "Show as Folders" or "Show as Links"? The reason I ask is that BZ https://bugzilla.redhat.com/show_bug.cgi?id=1263118 found a handful of unhandled NPEs in Project Explorer's client-side code that would lead to the View not being initialised properly. 

I am trying to replicate what you report (but there have been fixes made to Uberfire to improve "panel" resizing recently and the fix for the BZ I reference too, any of which could have improved the situation).
Comment 5 Jiri Locker 2015-10-01 10:57:57 EDT
Hi Mike, Project Explorer was (almost certainly) in Business (Project) View, showing links.
Comment 6 manstis 2015-10-01 11:51:29 EDT
Hi Jiri,

I managed to replicate the reported problem with Firefox (I couldn't replicate with Chrome.. that's not to say it didn't exist there too.. just it was impossible to reproduce). 

That said the DOM element in your screen shot represents an "Uberfire Dock" that now holds the Project Explorer. I've referenced a JIRA that fixed workbench layout/sizing when Docks were attached, expanded, collapsed or removed. 

I built kie-drools-wb here incorporating the change for UF-230 and was unable to replicate the reported issue with Firefox. I therefore feel confident this issue has been resolved.

Thanks,

Mike
Comment 7 manstis 2015-10-01 11:54:45 EDT
I should add, to better explain, the Dock holding the Project Explorer is automatically expanded when the Authoring Perspective is selected.. so the fix for UF-230 was relevant (I'd only mentioned UF-230 fixed an issue with expanding, collapsing etc which may have suggested User interaction was required).
Comment 8 Jiri Locker 2015-10-22 08:52:08 EDT
Still reproducible. Contact me for more information.
Comment 9 Jiri Locker 2015-10-27 13:56:52 EDT
I tried eap6_4 distribution from this location [1] and it was much easier to reproduce than with ER4.

[1] https://origin-repository.jboss.org/nexus/content/groups/kie-internal-group/org/kie/kie-wb-distribution-wars/6.3.1.20151024-225801/
Comment 10 Toni Rikkola 2015-10-28 07:43:30 EDT
I tried with the same build as Jiri did, but failed to reproduce using wildly and firefox.
Comment 11 Edson Tirelli 2015-10-28 14:47:05 EDT
Jiri, you mentioned you were unable to reproduce on our docks instances, but it was easy once you downloaded the war into your local machine and ran it there. 

I am wondering now if it might be environment related? Neither Toni nor Michael were able to reproduce, and it did not happen on the docker server... 

Is there anything specific to your machine? Can you try a fresh, from scratch, install on your machine and see if the problem persists?
Comment 12 Toni Rikkola 2015-10-29 04:08:14 EDT
For me it is not hard to believe that something is/was wrong. The Project Explorer does caching both on the server and client side. It also depends on events when loading up. Depending on browser speed, client to servers speed and many other interactions the content might not be shown due to a bad timing. 

Still our team uses it daily while developing and recently I haven't heard of any issues on this area.

I think I have said this before, but if we ever add new functionality to the project explorer or fix bugs there we should give a thought for removing some of the caching. I doubt it is needed. It was placed there to fix a possible problem. We didn't actually have a problem.
Comment 13 manstis 2015-11-02 05:11:25 EST
(In reply to Toni Rikkola from comment #12)
> For me it is not hard to believe that something is/was wrong. The Project
> Explorer does caching both on the server and client side. It also depends on
> events when loading up. Depending on browser speed, client to servers speed
> and many other interactions the content might not be shown due to a bad
> timing. 
> 
> Still our team uses it daily while developing and recently I haven't heard
> of any issues on this area.
> 
> I think I have said this before, but if we ever add new functionality to the
> project explorer or fix bugs there we should give a thought for removing
> some of the caching. I doubt it is needed. It was placed there to fix a
> possible problem. We didn't actually have a problem.

I don't believe the reported error relates to any caching issues. When the Project Explorer is "empty" resizing the panel shows the content correctly. 

"When reproducing manually it is possible to fix the condition by moving vertical splitbar".

Furthermore DOM inspection shows the elements have been appended to the DOM; however the outer most container has a width and height of 0.
Comment 14 Toni Rikkola 2015-11-02 06:45:07 EST
Yes, the problem here is probably not the cache, more about the project editor rendering before it loads the data. Just trying to point out that the project editor is really complicated. It lacks test coverage and it is not even MVP.

Caches are just another example of the complexity. I have blocked the adding of "refresh" button for project editor few times. Each time the need for it was just because caches did not work and the person who was making the change that required a change into cache codes, simply did not want to touch the code because it is hard to understand. (Not talking about you Michael, I see that you added the button in some time ago ;) Now we are in a situation where we have a really smart cache, but there is a refresh button. I don't know about the others, but when I see a refresh button I start wondering when it is needed and I hit it whenever I have a slightest doubt about not seeing the latest. This nullifies the need for the cache. 

Maybe this BZ is not the best place for this rant, but this bug is a result of the complexity. So we should keep in mind that rather than spending time on bug hunting bugs like this, we probably should just refactor/rewrite to MVP with good test coverage. Likely, we end up spending less time and getting the issue fixed.
Comment 17 Edson Tirelli 2016-01-04 09:53:35 EST
Since this is now low severity and Michael is still unable to reproduce, I am removing this ticket from the 6.2.1 patch.

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