Red Hat Bugzilla – Bug 1267901
Project Explorer sometimes empty after switching to Authoring perspective
Last modified: 2016-07-31 21:11:48 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):
Steps to Reproduce:
1. Start business central.
2. Log in, switch to authoring perspective
3. [repeat] Switch to home perspective and back to authoring
Sometimes Project Explorer remains empty.
Project Explorer should never be empty.
Created attachment 1079032 [details]
Empty Project Explorer
Created attachment 1079033 [details]
Empty Project Explorer (with Firebug inspection)
Screenshot with Firebug inspection illustrates that some HTML content is present but hidden.
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).
Hi Mike, Project Explorer was (almost certainly) in Business (Project) View, showing links.
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.
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).
Still reproducible. Contact me for more information.
I tried eap6_4 distribution from this location  and it was much easier to reproduce than with ER4.
I tried with the same build as Jiri did, but failed to reproduce using wildly and firefox.
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?
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.
(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
> 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.
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.
Since this is now low severity and Michael is still unable to reproduce, I am removing this ticket from the 6.2.1 patch.