Edit Mode: Prevent editable text selection on first click #65702
Conversation
youknowriad
added
[Type] Enhancement
youknowriad
requested review from
draganescu,
getdave,
mtias,
oandregal,
noisysocks,
jameskoster,
SaxonF and
richtabor
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -5 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
I think this will work well.
I'm noticing some inconsistencies in the interactions though.
For example, I can click directly on a Heading block and it will drop me into editing mode on that block immediately. Other blocks such as image seem to better respect the click once to activate/unlock section, click again to activate the specific block.
Personally I like the following flow:
- click section once - retains standard interaction model of Zoom Out but with a "flash" to highlight the editable blocks
- click section again - unlock/active the section for editing. All content blocks are editable.
- click outside section - section is locked again.
Screen.Capture.on.2024-09-27.at.11-36-40.mp4
|
@getdave the behavior you found I think happens because toggling zoom out also toggles design mode 🤷🏻 |
|
I added another commit that I would for it to be reviewed:
|
|
Testing this makes it more obvious we need to do some merging of modes before the next release, because one can independently change mode from tools and if one does that in zoom out, you cannot get back to zoom out. Here is a video using 6.7 nightly (the same works with GTB trunk) overlapping-mode-controls.mp4 |
|
What's missing in the current PR? I think we can land it no? |
|
Its still a little unpredictable. I can still select inner blocks on first click for example (see video) select-bug.mp4 |
draganescu
force-pushed
the
update/edit-mode-overlay
branch
from
647401b
to
90dcc61
Compare
| isSectionBlock( state, clientId ) && | ||
| ! isBlockSelected( state, clientId ) && | ||
| ! hasSelectedInnerBlock( state, clientId, true ) | ||
| ) { |
There was a problem hiding this comment.
I think this change makes it so that when the workspace (gray area) is clicked and then the canvas is clicked, while editing a page one ends up with the content block selected and a weird toolbar showing:
select-root-element.mp4
Maybe the removal of the check for getBlockRootClientId?
| @@ -42,12 +45,9 @@ export function useShowBlockTools() { | |||
| editorMode === 'edit' && | |||
| isEmptyDefaultBlock; | |||
| const isZoomOut = editorMode === 'zoom-out'; | |||
| const _showZoomOutToolbar = | |||
| isZoomOut && | |||
| block?.attributes?.align === 'full' && | |||
There was a problem hiding this comment.
Maybe we should not remove this condition in this PR, as this leaves blocks with no full with with no toolbar at all. Also #65627 is likely to land and also fix this.
There was a problem hiding this comment.
@getdave the behavior you found I think happens because toggling zoom out also toggles design mode 🤷🏻
I think it happens because there is an inconsistency in the PR. The PR title specifically states the goal is to "prevent editable text selection on first click".
My review above shows there is an inconsistency in the behaviour which @SaxonF has also found. I checked out the PR again to make sure I could still replicate it and sure enough...
Screen.Capture.on.2024-09-30.at.09-39-16.mp4
What's missing in the current PR? I think we can land it no?
I think we need to fix this before the PR is merged.
|
Ok, so it turns out that the inconsistency is actually a bug that already exists in trunk and that @ellatrix is fixing here. #65662 Basically, if you have a "stack" or "grid" and a paragraph within it, selecting the "stack" or "grid" automatically focuses the paragraph. It's visible here but it's actually unrelated. I'm going to review the other PR and try to land it. |
|
Works pretty good. One caveat that we need to account for: now that you can select the nested blocks to edit, you can double-click to select all the text contents of a block, but that disengages zoom out (due to double-click to exit zoom out). Can be a follow-up. CleanShot.2024-09-30.at.09.41.53.mp4 |
draganescu
force-pushed
the
update/edit-mode-overlay
branch
from
90dcc61
to
a9c5e10
Compare
|
@richtabor @jameskoster considering this PR is clearly the right path and it's gonna land soon how can we make interactions even more consistent. For example, if an image is between two patterns, with this PR selecting it will only show the section vertical toolbar. If an image is inside a pattern selecting it will also show the content trimmed block toolbar. While I understand how and why, it seems ... weird. The same applies to any block that is not in a container and is hence treated as a section. Should we just "make it so" that these blocks behave like the ones in containers (cc @youknowriad) or should we keep this behavior and come up with a way to convey "this is a section now"? |
|
Note I feel the need to disclose that this work has moved so fast that I haven't been able to keep my finger on the pulse, so apologies is any of these questions / bug reports are incorrect. I think I spotted a bug on this branch. While editing an empty page with zoom-out enabled and the template visible you can drag patterns from the inserter and drop them outside of the Content block. When you do they get inserted into the template / template part. This shouldn't be possible, right? You should only be able to drop into the Content block. In edit mode, when I select a section I don't see a toolbar, is that intentional? My expectation would be to see one containing the same actions as the one I find in zoomed out mode. The selection mechanic itself feels very unpredictable, I don't think it's working properly for me: selection.mp4
Is my build broken? :p
I suppose that is 'working as intended' but I agree the UX seems a bit strange. Maybe there should be exceptions for root-level non-container blocks? Almost like treating the Content block itself as a section. Another random issue, I'm missing actions (add before etc) in List view when Edit mode is active, is that intentional? |
I was able to reproduce this issue both in this PR and trunk. Let's track it. |
Personally, I think in this case, we're reaching the limits of the "vertical toolbar" experience. I wonder if it's better to always show the regular toolbar and avoid all this inconsistency and complexity. |
|
Testing with a keyboard. List View is quite broken on this branch. It is harder to move around between sections now with the keyboard, but it might be OK if List View is functional. The tab order of the vertical and block toolbars are out of place. If we do keep the vertical toolbar, it will need to come before the block toolbar in the tab order. Screen.Recording.2024-10-01.at.2.38.01.PM.mov |
youknowriad
force-pushed
the
update/edit-mode-overlay
branch
from
a9c5e10
to
7a24442
Compare
Related #65298 and #64197
What?
This PR starts the unification of "zoom-out" interaction model with the interaction model of "edit" tool/mode.
So it does the following in both modes:
For me, it does test well in both modes but would appreciate more 👀 to confirm that this behavior looks good and whether I missed some nuances.
Closes #65736
Testing Instructions
1- Insert some patterns in the post editor.
2- Enable zoom-out
3- Notice that you click sections to select them
4- Then you can click content blocks to edit text
5- Do the same test in "edit" mode.