[MGNLUI-3380] App launcher layout reloading mechanism is broken and bogus Created: 18/Mar/15  Updated: 13/Jul/23

Status: Accepted
Project: Magnolia UI
Component/s: applauncher
Affects Version/s: 5.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Aleksandr Pchelintcev Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: applauncher, observation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-405 AppDescriptorRegistry only fires chan... Closed
supersession
supersedes MGNLUI-3412 Admincentral crashes if app descripto... Closed
supersedes MGNLUI-1503 Optimize AppLauncherLayoutManager.get... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Story Points: 8

 Description   

There are several kinds of problems with App launcher layout dynamic reloading which lead to one consequence - the layout is not properly re-initialized upon changes. Things to check:

  • Conceptually: the changes notification usually comes from a separate thread (observation) but the AppLayoutManager synchronously tries to update the layout relatively to the current user (there is/should be none!)
  • In order to prevent the system eventbus listeners that handle the changes from leaking they are removed upon AppLauncher component detach (should only happen when the tab dies), but DeckLayout at times unnecessarily calls #remove(component) for AppLauncher (even though re-adding it in the same method) and the listener is wrongly removed. We should either ensure listener is re-attached or fix DeckLayout logic.
  • Internally in AppDescriptorRegistry when determining what apps have changed, added or removed - we conduct quite a few operations with collections which involve comparison of AppDescriptors which do not have #equals()/#hashCode() methods overridden. Such logic might be fragile.


 Comments   
Comment by Mikaël Geljić [ 18/Mar/15 ]

Nice overview,
I'm linking two issues I found from Tobias, that relate to this topic.

Generated at Mon Feb 12 09:06:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.