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: -83 B (0%) Total Size: 1.83 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
| @@ -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 |
|
Got it. In this case, I think if we allow switching between modes while in zoom out for now, we should also show the full controls when in Design mode with this PR. Don't mean to distract though if this is outside the scope. |
two-click-select.mp4 |
|
@draganescu Would you mind sharing the content of that page (or is it some existing page in 2025 or something)? |
youknowriad
force-pushed
the
update/edit-mode-overlay
branch
3 times, most recently
from
baf4093 to
b33cdf3
Compare
|
Flaky tests detected in b33cdf3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11461263367
|
|
Yeah the exacts steps to reproduce would help, I can't reproduce it either. |
|
Seeing a misplaced inserter: 
It seems to be the normal zoom out in-between inserter, but moved depending on the child selection. Question: right now in trunk it's not possible to select section children right? At least I can't seem to do it. |
|
@ellatrix good catch, it's fixed now and yes in trunk, it's not possible to select children of sections. |
|
This double click behaviour is sooo annoying in this mode. I constantly double click to select a word and it disengages zoom out 😕 Anyway, something to look at in a follow-up I guess. When I click child blocks in the inspector, the rich text toolbar does not load: 
|
| @@ -63,7 +62,6 @@ function useShallowMemo( value ) { | |||
| */ | |||
| export default function useNestedSettingsUpdate( | |||
| clientId, | |||
| parentLock, | |||
There was a problem hiding this comment.
Just curious: why is this no longer changes and what required the changes to the selectors?
There was a problem hiding this comment.
Basically I did a refactor to how "templateLock" works. Instead of doing the "inheritance" of template lock when setting the templateLock in the state, I moved the inheritance to the getTemplateLock selector instead.
The reason is that we want to know precisely what container have an explicit templateLock and what container inherit templateLock. Because the ones that have an explicit "contentOnly" templateLock are considered sections but not the ones within them.
There was a problem hiding this comment.
I think at some point we may want to investigate these selectors (and the other few similar recursive selectors), I suspect they're not performant, which can be seen in the difference between the "preview" block selector and the normal one.
|
Yes, I think we should probably remove the double click now. Can do either here or in a follow-up. |
|
IMO we should remove it entirely. I think it's inconsistent with other interactions we have around blocks tbh. |
With the ability to edit text directly when zoomed, it feels like double click might now be redundant. Just noting that this is not the case with WP 6.7, as the Zoom Out experience in |
|
Thanks for sharing the content by DM @draganescu I managed to fix the issue. |
There was a problem hiding this comment.
I was so zoomed into zoom out that I missed that this PR "does the following in both modes:" - both. I would like to offer my negative opinion about having to click twice when edit mode is enabled and the user is in default view default scale. It's clumsy and serves no purpose.
Things that are editable should be immediately editable by activating them (click, focus). We are expanding the UX in pattern overrides to the whole canvas for no benefit - but at least in pattern overrides it serves the purpose that in one of those patterns only some content is editable. But in content only write mode all content is editable - only content, but all of it.
There is no point in applying a double click drill down UX to the whole canvas in default view default scale in write mode and it seems it's done here for some ideal of consistency.
Not even consistency is served though, since views, like modes, afford new affordances. To give an example a shape in a 3D view has three handles to drag on, but seen from any of the 2D views it only has two handles. And it makes sense, we don't need a 3rd handle in a 2D view, because it beats the purpose of the 2D view. Just like maybe we can have double click drill down UX in zoomed out view at small scale to favor interacting with larger areas of content.
Can we do what this PR does but only in zoomed out view? Or is this a no go? Or am I missing something fundamental?
Reported here: #65750 |
youknowriad
force-pushed
the
update/edit-mode-overlay
branch
from
0c7161a to
683c073
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.