Add feature for adjusting meta box split view with wheel gestures - #75220

Size Change: +820 B (+0.01%)

Total Size: 8.76 MB

_{compressed-size-action}

It would be nice if the diff is minimized by avoiding file moves to make it easier to review and see what's changed. Or is that not possible?

It’s totally possible to avoid file moves. They are done atomically so leaving the first couple commits out of the diff shows what actually changed.

To me, it seems past time the MetaBoxesMain component had its own file. I could make the file moves a separate PR though.

How about enabling this feature by default and providing a way for users to opt out if we have negative feedback?

I tend to agree it’d be fine to enable by default. While I generally agree with avoiding extraneous options, I do think this feature can be annoying, so I like the idea of preference. I wouldn’t say it needs to be via the dedicated button in the splitter bar though.

The main way I find this annoying is in scrolling upward. If starting at the end of the canvas it shrinks the pane. It seems easy enough to wheel to the end without unintentionally adjusting the split, but when you start to go back up it’s going to shrink it. I suppose there may be some way to make the logic smarter around that – like if you got to the end without causing it to adjust then don’t adjust it as you head back up.

How about enabling this feature by default and providing a way for users to opt out if we have negative feedback?

I tend to agree it’d be fine to enable by default. While I generally agree with avoiding extraneous options, I do think this feature can be annoying, so I like the idea of preference.

@ellatrix @Mamaduka What do you think about this point?

Hm, can we try to enable it without an option first and see what people say? It's always easy to add an option later but not to take it away. Ideally it's very smooth and doesn't immediately active on pull of a few pixels, but sort of animates upwards to show people what would happen when you scroll out of bounds more. Sort of like a reverse pull to refresh. :)

Pardon the delay but now I've updated to remove any new/moved files and removed the preference and button to toggle the feature.

It's always easy to add an option later but not to take it away. Ideally it's very smooth and doesn't immediately active on pull of a few pixels, but sort of animates upwards to show people what would happen when you scroll out of bounds more. Sort of like a reverse pull to refresh.

The idea to add the preference doesn't come from a concern about the activation when scrolling out of bounds or to the end because it doesn't trigger too easily. Instead it's about scrolling up from the end when split has been set as somewhere in the middle and is desired to stay there. Regardless, the preference is now removed so we can see.

Flaky tests detected in 6850f82.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23263564139
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should not highlight more than one format #48529 in /test/e2e/specs/editor/various/rich-text.spec.js

Thanks for working on this!

I noticed something when I tested it again. If I scroll while keeping the mouse position completely fixed, it may get stuck midway through. Please watch the video below.

RC1 is today so this is probably too late to land in 7.0 now? I welcome other opinions 🙂

I feel that a few more tests are needed. Perhaps we can ship this PR alongside the fully iframed post editor in 7.1?

If I scroll while keeping the mouse position completely fixed, it may get stuck midway through.

Thank you for testing and raising this. I'm aware of it. As best I understand, browsers have some sort wheeling session logic where wheel events are dispatched to the initial target. Besides moving the pointer, if you stop wheeling for some duration then try again it should no longer be stuck. I think the timeout varies per OS/browser. In practice, I doubt it's much of a concern because if you are revealing the pane you are presumably going to move the pointer to do something there before engaging the adjustment again. I've attempted to find a workaround and didn't succeed but there could be a way.

Please note that in the upcoming 7.1 release, the post editor will be fully iframed. Based on user feedback, let's consider whether we should proceed with this for the 7.2 release.

Please note that in the upcoming 7.1 release, the post editor will be fully iframed. Based on user feedback, let's consider whether we should proceed with this for the 7.2 release.

+1 Please proceed with this for 7.2. Right now, the post editor is a nightmare to move between the YoastSEO block and the post editor. My workflow has been destroyed since this bug/behavior was introduced in 6.8.1, and now with 7.1 there won't be a workaround anymore. Make it a separate plugin, a mu-plugin, whatever it is needed if WordPress devs won't let you included it in core, but please help us poor users who write blogs every single day and instead of focusing on writing, we have to drag that metabox up and down 100 times to finish a blog post. Thank you!

we have to drag that metabox up and down 100 times to finish a blog post

In case it helps, instead of dragging, clicking the panel header toggles it. Click anywhere except the center resize bar.

🤖 PR meta 🤖

🎉 Props

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @GH-User865.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: GH-User865.

Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +910 B (+0.01%)

Total Size: 8.26 MB

_{c523e95 Run}

⚡ Performance

_{c523e95 Run}

I made some changes with the help of AI and plan to test this PR shortly to see if we can ship it for the 7.2 release.

I've tried a few things, but in my environment, the scrolling still isn't completely smooth in some cases. For now, I'd like to keep the milestone as 7.2, but if we can't find an effective approach, I'm open to postponing it.