Something that reads from the category manager on initialization, also adds observers for “xpcom-category-entry-added” and “xpcom-category-entry-removed”, and on initialization OR when the category in question (browser-newtab-ui-component) changes, we reconstruct the list of components
Potentially reuse CatManListenerManager, which does the above (but we need to recompute the categories on notifications)
Interestingly, the CategoryManager has its entries populated from manifest files for each process, meaning that we’d get build-time registration for free in the privileged about content process. What we wouldn’t get is dynamic registration and unregistration
Have the backend newtab code iterate the relevant categories, and get the return values for each entry in the category, and then to sort them by type.
This will then create a structure which can be send down in the state object that each New Tab receives - A class (or component?) will be responsible for parsing that structure and holding it per page - Yes, it’s awkward that each instance of newtab has one of these, but that’s already a problem with the state object - The Search.jsx component will get the definition for the lone “search” item in the registry. When it finds it, it will insert the script and insert a web component (React, Lit, vanilla) that is responsible for adding stylesheet dependencies within its shadow dom or via CSS modules.
I need to start an Engineering Design document to start shopping around with these ideas, at least show Gijs and Scott, but probably a bunch of others as well.
File a bug to get rid of non-handoff behaviour to simplify Search.jsx and contentSearchUI