This Spike is quite open-ended, so I’ll break this analysis down into 2 parts.

1. Current Page Tools compatibility with gadgets
2. How can we enable gadgets to use the new Pinnable functionality.

Page Tools gadget compatibility

Twinkle

✅ Works with Page Tools menu (pinned and unpinned)
The TW menu inserts itself after the Page Tools menu.

MoreMenu

✅ Works with Page Tools menu (pinned and unpinned)
The "Page" menu is inserted before the Page Tools menu.
The "User" menu, only visible on user pages, is also inserted before the Page Tools menu.

ProseSize

✅ Works with Page Tools menu (pinned and unpinned)

RTRC

✅ Works with Page Tools menu (pinned and unpinned)

“Allow navigation menus to be collapsed”

• ❌ Does not work for any menus in Vector 2022, but possibly superseded by future designs

“Add a toolbox link to reload the current page with the system message names exposed”

✅ Works with Page Tools menu (pinned and unpinned)

• adds the "messages" item in the Page Tools menu

“Add a toolbox link to reload the current page with Resource Loader in debug mode”

✅ Works with Page Tools menu (pinned and unpinned)

• adds the "debug" item in the Page Tools menu

Summary

After examining various gadgets, I haven't found any adverse affects related to the new Page Tools menu. I tested gadgets in production as well as locally and didn't see any breakage (except for the collapsible menus gadget).

We were able to maintain compatibility for a few reasons:

1. The Page Tools menu is rendered server-side, which maintains the expected JS execution order (i.e. the expected HTML menu exists when the gadget JS executes).
2. We maintain the same IDs that were previously used to target this menu by gadgets.
3. When we move the menu, we maintain the JS behaviour and events that have already been bound to the HTML elements by gadgets.

Although not available on production yet, I also tested the Page Tools persistence feature with gadgets and did not notice any loss of functionality. The only noticeable difference is that, when the menu is pinned by default, you can sometimes see the addition of new links after the page loads. This could potentially cause a layout-shift, but that would only be an issue if the Page Tools was pinned by default for anonymous users and a gadget that adds a link was also enabled for anonymous users (unlikely).

@Jdrewniak - any chance you can take a quick look at T325097: Updated tools menu for Vector 2022 breaks on-wiki scripts before we close this out?

I left a comment on T325097 for that specific script. I think reverting the last edit should resolve that issue (it was caused by a workaround for T315639).

Regarding the second part of this spike, exposing the Pinnable functionality to gadget, I have a short write-up below.

Enabling gadgets to use the PinnableHeader

In order to expose the pinnable functionality to gadgets, the following technical refactors would have to happen:

1. Package the PinnableHeader component as a resourceLoader module. This module would have to include the related styles, javascript and templates for the PinnableHeader.
2. Provide an imperative way to instantiate the PinnableHeader. Currently, the pinnableHeader is initialized declaratively by looking through the DOM for a .vector-pinnable-header class (on pageload). Gadgets kick-in after pageload, so they would need to instantiate the pinnableHeader themselves via JS. A constructor-based approach like new PinnableHeader() might be more appropriate for this use case.

However, exposing just the pinnable header, without the related menu templates, doesn’t make much sense since they work in unison. That topic is covered in T303859.

Another open question about exposing pinnability is how useful is it without a persistence layer (I’d argue not very much). We currently tie pinnability to a user preference, but gadgets don't have that ability. They could however, use localStorage instead (which is reasonable). In order to support that though, we would have to refactor the pinnable header code to accommodate multiple persistence strategies instead of just the one we have now.

Another question is how useful is this functionality to gadgets in general? Currently, pinnability really only works when moving a menu from the tabs into the end-column. What about moving a menu into the start-column? (ToC sidebar) or into the header? or from the header into the tabs? Although our API is generic enough to handle this, we haven't tested what these variations would look like outside our specific Page Tools use-case.

Summary

I'd recommend further exploration before undertaking this work. More generic UI customization is desirable, but pinnability feels like a very specialized feature that would work in a well-defined framework. I'm not sure it's something we can build upon to move towards that kind of framework though.