Steps to reproduce:
- Add a Fragment Collection
- Add a Fragment Entry with a widget (<lfr-widget-nav></lfr-widget-nav)
- Create a page template and add the fragment
- Configure the fragment so that it shows the secondary navigation menu
- Reload the page
Expected result: The product menu is functional
Actual result: js errors are thrown in the console and the product menu is not functional
Extended steps to reproduce:
0) Go to Build -> Page Fragments, create a new collection and a fragment in it with the following code:
1) Go to Build -> Pages -> Page Templates, create a new Collection and a Content page template in it, add the fragment from (0) to the page template.
2) Add a breakpoint in ScriptDataPortletFilter, line 77 (_flushScriptData call),
3) Go to the page template from (1) and refresh it. When it stops on the breakpoint (2), check that current portlet is Navigation Menu, but the only ScriptData in the request belongs to the GroupPagesPortlet(screenshot 1).
4) Add a breakpoint in FragmentEntryRenderUtil, line 146(return of renderFragmentEntryLink call), continue with the execution.
5) When it stops on the breakpoint (4), check that rendered html of the fragment contains script, which belongs to the GroupPagesPortlet (screenshot 2). Disable breakpoints and continue.
6) On the Page template, try to open a product menu, assert JS error in the browser console, product menu doesn’t work, sidebar fails. (screenshot 3). It happens because the script loaded in (4) was already loaded and executed and when it happens with the Metal.JS components (Chema, correct me if I’m wrong), we are registering twice the same component, and even in our own code(see component.es.js, line 176) we warn the users that it can lead(in fact, it leads) to the unexpected behaviour.