ResizableBox - Resizing via drag handle or numerically should be proportionally unless using modifier keys

[porg]

Description

How certains resizing aspects should work - And how they actually work or fail

1. Resizing via drag-handles: Resizes proportionally.

   • Modifier key to temporarily override proportional resizing: Not offered. Would be fine.
   • Proposed modifier keys should respect design app conventions:
     • SHIFT to toggle proportional resizing (without modifier the default should be proportional)
     • ALT to resize from the center (where appropriate).
     • CMD to toggle snapping to nearest preset aspect ratio (should this get implemented)
   • As soon as you trigger a manual override, the dropdown menu (as in the mock-ups of Image block: Implement aspect ratio control #51138) would need to update to "Custom".
     • Further resizing would maintain that "Custom" AR.
     • Using the modifier key again later would update the "Custom" AR again to a new value.

2. Resize image by number fields

   • Mostly resizes without maintaining aspect ratio. That‘s a bug if an aspect ratio is set.
   • But a few times I experienced that numerical resizing (by either of the three methods: number input, arrow-up/down keys, arrow up/down buttons within numfield) maintained aspect ratio!
   • I cannot reproduce the precondition reliably, but the instance I remember, prior to num-input I had resized via handles.

Step-by-step reproduction instructions

See above.

Screenshots, screen recording, code snippet

WordPress.Image.Block.1.drag.handles.resize.proportionally.mp4

WordPress.Image.Block.2.numerical.input.resizes.not.proportionally.mp4

WordPress.Image.Block.3.numerical.input.sometimes.resizes.proportionally.mp4

Environment info

• WordPress 6.2
• Plugin Gutenberg 15.9.1
• Safari 16.5
• macOS 11 Big Sur

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

No

[porg]

CC: @ajlende I filed this as a stand-alone issue as you requested.

[ndiego]

Now that #51138 is merged, @porg would you be able to retest using the latest release candidate for 16.1, or 16.1 when it comes out later this week. There have been a lot of changes to the Image block with respect to aspect ratio.

[porg]

@ndiego I'm willing to test this

• But I have no WordPress development environment.
• So far I used http://gutenberg.run/pull-request-number-here
• Could you please provide me the relevant PR number which can be tested there?
• Or as I know that you work for a company which provides WordPress staging solutions, could you offer me an account there where I can run Vanilla WordPress+Gutenberg installations to conduct testings?

[ndiego]

@porg there are many ways to set up a local WordPress dev environment. Here are some official docs: Setting up a Development Environment. Personally I use LocalWP, which is free, for all my testing and Gutenberg development.

[github-actions]

Help us move this issue forward. This issue is being marked stale since it has no activity after 15 days of requesting more information. Please add info requested so we can help move the issue forward. Note: The triage policy is to close stale issues that need more info and no response after 2 weeks.

[porg]

✅ Tested in Gutenberg plugin 16.2.1:

• Getting non-proportional sizing with the new aspect controls is now much less likely.
• In general this aspect ratio control is a big step forward, has a lot of improvements
  • Especially standing out is the avoidance of oversampling with aspect-ratio: original, width : auto, height: auto when having chosen a low resolution source image.
• There are some dead-ends into which you can navigate yourself into, but resetting to aspect-ratio: original, width : auto, height: auto, and then starting over got me rid of any distortions again. At worst create a new image block afresh.
• Overall much more robust now!

From my side we can close this issue now.

[jordesign]

Thank for the additional testing @porg - that's great to hear. I'll close this for now - and we can re-open if those dead-ends become more common