[MGNLUI-4269] SearchContentToolPresenter & View: Opening multiple apps seem always to operate on the search presenter & view of the first instantiated app. Created: 14/Aug/17  Updated: 21/Aug/17  Resolved: 21/Aug/17

Status: Closed
Project: Magnolia UI
Component/s: app framework, content app
Affects Version/s: 5.4.13, 5.5.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Not an issue Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File SearchContentToolViewImpl-FullyWorking.patch     Text File SearchContentToolViewImpl-v1.patch     Text File SearchContentToolViewImpl-v2.patch     Text File SearchContentToolViewImpl-v3.patch     Text File SearchContentToolViewImpl-v4.patch     Text File more-debugging.patch    
Issue Links:
causality
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:

 Description   

I tried to implement for this support ticket SUPPORT-7792 following:
In the view SearchContentToolViewImpl using a ShortcutListener instead of a Property.ValueChangeListener.
The goal is, that only on KeyCode.ENTER a search is triggered, but not when leaving the field.

This lead to a very strange behavior:
I added a couple of patches. The patch 'SearchContentToolViewImpl-v1.patch' should work properly, but:
It works perfect with one app. But if you start a second app, operates on the view and presenter objects of the first app. Therefore also operates on the TextField and ShortcutListener from the first app!
But the target object (TextField, ShortcutListener.handleAction(Object, Object) ) is always the right TextField of the correct app.

Reproduce with any of the patches:

  • Starting App A
    • Do a search -> works
  • Starting App B
    • Do a search -> Operates on the SearchContentToolPresenter and SearchContentToolView of App A!! -> See in the logs (or debugger)
  • Close App A and App B works perfect and operates on the objects as expected.

I created 5 patches so you can look at it easily:
SearchContentToolViewImpl-v1.patch: The code that should work
SearchContentToolViewImpl-v2.patch: Not as a private variable
SearchContentToolViewImpl-v3.patch: Returning the targetTextField and not the searchField (priv member) to the presenter. I expected that this works.
But they operates crossways -> App A gets parameter of App B, and App B gets parameter of App A! (see in location fragment)
SearchContentToolViewImpl-v4.patch: searchField not final and overridden with targetField -> same behaviour as V3
more-debugging.patch: Some more logging and passing of objects to proof that it operates actually within the wrong app.

I also ran to code agains 5.4.13, same behavior (suspected Guice changes of possible cause)



 Comments   
Comment by Aleksandr Pchelintcev [ 21/Aug/17 ]

Hi,

cringele As Vaadin forum thread suggests, in order to get the shortcuts to work in a more predictable way, you have to fallback to the "wrap-the-view-in-panel" workaround. I don't see the references to attempting that approach in the issue description. However, I see that the second patch tries to utilise it, but incorrectly (see arrow comments in the snippet):


         searchField = buildSearchField();
 
+        Panel panel = new Panel();
+        panel.setContent(searchField); <----- Field is attached to the panel!!
+        panel.focus();
+        System.out.println("=====================");
+        System.out.println("Iinitialization start");
+        System.out.println("view id init: " + this.hashCode());
+        System.out.println("searchField id init: " + searchField.hashCode());
+        System.out.println("=====================");
+
         setVisible(true);
         addComponent(searchField); <- Field is re-attached to the root layout (removed from panel)!!
         addComponent(clearSearchBoxButton);

In order to arrange it right, it is the wrapper panel what should've been attached to the root layout, so that it becomes a part of component hierarchy.

Comment by Christian Ringele [ 21/Aug/17 ]

Attached the fully working patch 'SearchContentToolViewImpl-FullyWorking.patch'.

  • The ShortcutListener must be wrapped into a panel
  • The ShortcutListener must be added to the panel as listener and not to the textField itself.
Generated at Mon Feb 12 09:15:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.