when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy)

Render things in the area which the menus occupy

the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient?
is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode)
do we always want to collapse the sidebar or are there situations where we dont want to do this?

Our initial requirements would just be a call that could hide/suppress the sidebar so that the VE could reserve that space for EditCheck. VE would be responsible for restoring the sidebar after.

while the right rail is collapsed is it possible to pin anything there via user interaction (my assumption is no)

No

Render things in the area which the menus occupy

Oh I misunderstood this then. Glad I asked! I thought you were rendering edit check in the surface area for VE. So you would need the HTML container that the page tools is currently in to be empty but present in the DOM so you can render inside it?

@ppelberg the web team discussed this yesterday and think that it can be declined, as it is our understanding the editing team found a way to do this without our assistance. Is that your understanding too?

We did do it (in a somewhat-hacky manner). The main drawback of our approach is that we're outright hiding the sidebar, rather than properly collapsing it. I.e. if someone has things kept in the sidebar, they are gone until they leave VE.

The notional thing that a proper API might provide for us would be collapsing the sidebar items back into their menus temporarily (and without storing the preference), to preserve access to their contents during an edit. In particular, someone who's editing might very well want to tweak the appearance menu and see how e.g. a table they're making looks with the largest possible font-size. (There's also a few things that someone might potentially want to look at in the tools menu, but that's all accessible by opening a new tab.)

Thanks for the update! I swept it back into our backlog. Let's talk about it in our next editing/web sync!

Next step(s)

Per offline discussion with @medelius, @HFan-WMF, and @Jdrewniak today, the Editing Team is going to assess the extent to which we are in a position to implement the Requirements the description holds.

Note: were the Editing Team to take on this work, the Reader Experience Team would be in the position to determine the viability of a given technical approach (read: reserve right to +2 any code).

1. when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy

We're currently removing the menus entirely, and rendering things into the area they were taking up by expanding the width available to the VisualEditor. This means it's all within the now-expanded content area.

We accomplish this via .ve-editcheck-available .skin-vector-2022 .mw-body .vector-column-end, .ve-editcheck-available .skin-vector-2022 .vector-pinnable-header-pin-button { display: none !important }

2. the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient?

I don't think we care about the current state, per-se. We want to make a call that tells these to get out of our way, and then later make a call that tells it that menus can return if they need to. That can all be done without knowledge of the state in our code. (And is better that way, because it means we don't have to pass that state around internally.)

3. is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode)

I think it's simplest if restoring is handled by the caller -- we can tell it to hide on initial setup, and tell it that restoration can happen on teardown.

4. do we always want to collapse the sidebar or are there situations where we dont want to do this?

Currently we want to collapse it whenever edit checks are potentially present, because they need a sidebar and doubling-up sidebars is a problem for content. We already have the logic for this implemented, and only apply our hack when edit checks could be present.

We've discussed hiding the sidebars in general during editing, but haven't gone ahead with it so far.

5. while the sidebar is collapsed is it possible to pin anything there via user interaction (my assumption is no)

No. Stopping people from pinning things there in this mode is the entire point.

Per offline discussion with Editing engineers, the Editing team will move forward with implementing this ourselves, with Reader Experience team responsible for +2.

Change #1235389 had a related patch set uploaded (by Medelius; author: Medelius):

[mediawiki/core@master] WIP: Create util methods for freeSpace and restoreFreedSpace

https://gerrit.wikimedia.org/r/1235389

Change #1235390 had a related patch set uploaded (by Medelius; author: Medelius):

[mediawiki/skins/Vector@master] WIP: Add handlers for new freeSpace and restoreFreedSpace hooks

https://gerrit.wikimedia.org/r/1235390

Change #1235391 had a related patch set uploaded (by Medelius; author: Medelius):

[mediawiki/extensions/VisualEditor@master] WIP: EditCheck: Use new freeSpace hook to disable sidebar during editcheck workflow

https://gerrit.wikimedia.org/r/1235391

Hey Editing Team,

Jon handed this off to me before he left for vacation and the Reader Experience team has been discussing potential paths forward. While the approach in @medelius's patches is sound and makes a lot of sense from an API workflow standpoint, we have some concerns about the new mw.util methods:

• We should probably limit what things can modify the Vector sidebars, possibly to VisualEditor only. We don't want to enable just any extension/gadget to toggle such important menus. Plus, we wouldn't want to have to handle a collision of content in the sidebar areas from multiple extensions/gadgets.
• The core hooks are quite general, implying that they could be handled in multiple skins. However, this particular issue is specific to the Vector 2022 sidebars (what we call the start and end columns, the start column containing the main menu, and the end column containing tools and appearance).

I looked into repurposing or extending mw.util.hidePortlet and showPortlet, but that would require mucking about with a fairly long-standing core API and would require you to hide/show each individual portlet within each sidebar, which seems brittle. We also considered whether there was a reasonable way to define an API in Vector itself to provide control over what's in the grid columns, but this seems like overkill and is a bit backwards when it's really Vector that needs to respond to a change precipitated by VE.

So, we think it makes sense to limit the scope of this work and use the hooks system in a more straightforward way. We propose the following:

• Define hooks in VisualEditor that hide or restore Vector columns. If you'll ever want the granularity to hide one sidebar at a time, you could create hideVectorColumn and restoreVectorColumn hooks that take in a column name as a parameter. Otherwise, you could just create hideVectorSidebars and restoreVectorSidebars hooks. Or some better names.
• Listen for these hooks in Vector and respond accordingly by unpinning or pinning the menus within the columns. Caro's Vector patch already does this; we have some minor suggestions for streamlining this patch but that can be handled in code review.
• Remove the core patch.

This would give you the flexibility to call these hooks just for EditChecks or for more circumstances in the future (I saw that you have a task for hiding these menus for all VE users if it's found to be beneficial, and even if that's not moving forward, I'm assuming you may have need for this kind of control in the future), while restricting the ability to do this to VE. All of the handling would happen in Vector and the only interdependence between the two would be the hook names.

Please let me know what you think, or if you have any better ideas! Happy to discuss synchronously if that's easier. Thank you for your patience as we worked to provide this feedback to you.

We don't want to enable just any extension/gadget to toggle such important menus. Plus, we wouldn't want to have to handle a collision of content in the sidebar areas from multiple extensions/gadgets.

I'm not sure this is something that's really within Vector's control? It's already easy for extensions / gadgets to hide the Vector sidebars; the purpose of this API is just to improve the experience for users when that happens by making sure they retain access to the contents of the menus, and to reduce the odds that extensions/gadgets will wind up stepping on each others' toes by simultaneously trying to hide the sidebars in their own bespoke manners.

That said, I do agree that as-is Vector is the main offender in terms of constraining content space, and it's not like we have plans to proactively go out and support other skins for this, so from a WMF-perspective just hacking some further connection into place between Vector and VE would generally work out for us. The main thing I think we care about is that the code responsible for all the expanding/collapsing remains within Vector, so it won't bitrot away within VE when changes occur.

I see your points, @DLynch. One of my assumptions was that we want to generally discourage hiding the sidebar menus, unless it's for a carefully considered reason and we have some evidence that it benefits users instead of hindering them. But I'm not as aware of the existing ecosystem of stuff that already does that. I'm coming from the perspective of exercising caution before developing a more visible, generalized API, because doing so sanctions and promotes use of that API, likely in ways we don't expect. My team is dealing with a significant maintenance burden so we're attempting to limit introducing more complexity wherever possible to ensure we can spend our time with the greatest effect. I agree that keeping most of the code in Vector is critical here, and I hope that would allow us to generalize a system for responsibly hiding menus (or increasing available space, or however you want to frame it) for wider use fairly easily in the future, should that ever be justified.

Change #1235389 abandoned by Medelius:

[mediawiki/core@master] Create util methods for freeSpace and restoreFreedSpace

Reason:

Abandoning in favor of an approach that doesn't require hooks in core and keeps the workflow between Vector and VE only. See T379444.

https://gerrit.wikimedia.org/r/1235389

Change #1244703 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Refactor pinnable elements to remove TOC edge case, improve code reuse, and rename methods for clarity

https://gerrit.wikimedia.org/r/1244703

Change #1235390 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add handlers for new hideVectorColumns and restoreVectorColumns hooks

https://gerrit.wikimedia.org/r/1235390

Caused T419620: [beta cluster] "TypeError: hasPinnedElementsFn is not a function" warning

Change #1235391 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] EditCheck: Fire new hooks to hide/restore Vector sidebars

https://gerrit.wikimedia.org/r/1235391