Gutenberg 7.4 bug. When the toolbar is set on top the icon to click and drag the selected block goes missing.

[nick6352683]

Describe the bug
When the toolbar is set on top the icon to click and drag the selected block goes missing. The icon to move the block with the mouse is there if the toolbar is NOT set on top.

To reproduce
Steps to reproduce the behavior:

1. Set the Toolbar on the blocks - all is fine
2. Set the Toolbar on top - the move icon is missing

Expected behavior
All the block option icons to be present when the toolbar is set on top.

Screenshots
Here is a short video proof: https://www.youtube.com/watch?v=KRr2nibeaf4&feature=youtu.be

Desktop (please complete the following information):

• OS: Windows 7 Pro, Xampp WP 5.3.2, Gut 7.4, Php 7.2x
• Browser Chrome
• Version 79.0.3945.130 (Official Build) (64-bit)

[jorgefilipecosta]

Hi @nick6352683, thank you for reporting this issue.

Removing drag & drop on the top toolbar seems to have been intentionally done in #20013.

@mapk, @epiqueras are we planning on allow drag & drop somehow when the toolbar is enabled? If for example, I want to move a paragraph to the end of a post with multiple paragraphs not having drag & drop will require many clicks on the mover to do that. Some users always use top toolbar and don't even know other modes exist so for them not having drag & drop may seem a bug that makes the editor harder to use.

[nick6352683]

Hi @jorgefilipecosta,

If drag & drop is intentionally removed, how do I move a block into a column, or a group? The only possible way is to save the block as a reusable block, then insert the reusable block in the column or group, and then delete the original block.

Is there a setting or a way with code to bring it back? Unless I'm missing something, removing this action from the toolbar, is one of the worst decisions ever made in regards to Gutenberg... we might as well remove the option to remove the option to have the toolbar on top.

A second option is to turn off the top toolbar, move the block inside a column or group, and them turn on the setting to move the toolbar back on top. In either case, it always ends with me being very frustrated,

Sorry for my moderately harsh words, I need to be little bit controversial to get more eyes on this... once again sorry...

[epiqueras]

Having the mover up there is confusing. You would be initiating a drag that moves something elsewhere on the screen.

We would need to keep the movers inline somehow even when the toolbar is set to the top.

[jorgefilipecosta]

Having the mover up there is confusing. You would be initiating a drag that moves something elsewhere on the screen.

Yes, I also think the mover at the top is not a good approach.

We would need to keep the movers inline somehow even when the toolbar is set to the top.

Exactly, I think the new design being worked on will address this issue. But it seems we will need a temporary solution in WordPress 5.4, otherwise, the experience will look broken e.g: as @nick6352683 referred moving a block to be inside another one is impossible.

[jorgefilipecosta]

Hi @nick6352683, once again thank you for sharing your thoughts and raising awareness to the issue. I'm sorry this issue made Gutenberg a frustrating experience for you.

[nick6352683]

@jorgefilipecosta , I am really grateful to you for understanding the issue and hopefully finding a solution for it. The original way of working was perfect, where even the toolbar was on top, the up and down arrows, along with the drag & drop were inline...

Once again, thanks.

[epiqueras]

Can we not revert to that? Why did we move them to the top with the toolbar?

[mapk]

Can we not revert to that? Why did we move them to the top with the toolbar?

I believe they got moved to the Top Toolbar because the movers were placed inside the block toolbar now. It is definitely frustrating.

Can we keep the movers inline with the block regardless? Something like this:

[nick6352683]

Can somebody in charge please make a decision on this, there are really 3 options here:

1. Do nothing, and force people to change the toolbar location from top to inline, just to move a selected block inside a container, like Cover, Group, Columns, etc...
2. Leave the movers on top, but give us back the click to drag button - even though it might be awkward for some, they will get used to it in a few days (there are way too many awkward things with Gutenberg), this is one of the least one of them...
3. Keep things before Gut. 7.2 ?, where the movers were ALWAYS inline, and never on top no matter where the toolbar's location was.

P.S. Thanks Mark for chiming in...

[oldrup]

Having created all my content in Gutenberg in a loong time, advocating and promoting Gutenberg in the local meetup groups, I must say, I feel that making such radical changes mandatory for users, without leaving them with even an option to continue their existing workflow, makes me think twice before recommending Gutenberg again. I just tried to give the 7.7.1 another spin, as WP Tavern comments praises its new approach. And I might be getting old, but I really think this is a step backwards. Please consider making drag and drop an option again, even with the toolbar on top (where it is out of contents way)..

[joanrho]

GIF screengrabs of current experience:

• Moving a paragraph block with Top toolbar active: https://d.pr/i/dgAL7Z
• Moving a paragraph block with Top toolbar inactive: https://d.pr/i/v46VFD

Screenshots:

As I was testing out the current block mover controls experience in the two above scenarios, I was a bit confused by the following:

• When a block is selected, I can't just drag and drop it by clicking and holding on the element. This is a common, expected pattern you see around other products that allow for spatial movement of elements, like Trello, Github project boards, etc. where a single click selects the element or opens the card, and a longer click-and-hold allows for element drag and drop.
• Also when a block is selected, the block mover controls are not visible. They're only revealed when I hover over the block switcher icon (here in my demo, the paragraph icon), which didn't feel intuitive because clicking on the block switcher icon button reveals the block switcher popover. This difference in hover and click behavior on the same button felt a bit confusing to me. This also differs from what happens when the Top toolbar is active: hovering over the block switcher icon does nothing, yet clicking on it opens the block switcher popover. We should be consistent with the hover behavior of the block switcher icon whether the Top toolbar is active or not.
• It wasn't clear or intuitive that I could click and drag the mover control arrows (when they appeared) to drag and drop my selected block. Perhaps the tooltip text over that element needs to mention that, or we should bring back the drag handle to indicate that the element can be dragged and dropped.

Suggested changes:

1. Bring back the drag handle to indicate drag and drop capability.
2. When a block is selected, always keep mover controls visible and displayed next to the selected block, even when the Top toolbar is active.
3. Really nice to have, if it's possible: A long click-and-hold anywhere on the element should call forth Selection mode to drag and drop it, just as it would if a user had clicked directly on the drag handle to move it around.

If folks feel strongly that the drag handle is not a necessary affordance, here's a proposed "middle ground" solution that only applies the second proposed change above but maintains the minimal arrow styling from the current experience:

[mapk]

Thank you for that feedback, @joanrho. It's great to see it all together like that.

When a block is selected, I can't just drag and drop it by clicking and holding on the element.

This would be great to solve, but it gets real tricky. Trello seems to work like this:

• Long press without moving the cursor does nothing.
• Letting go after long press without moving opens the details modal. It reacts the same as just clicking on it.
• Long press and moving slightly pulls card out of place and tilts it, and leaves a shaded area in the background.

The first problem I see with this in the block editor is that this interaction may conflict with highlighting text in a block because they both require a long press while moving the cursor.

Most graphic programs require one click to select the text block and another click to get into the text (ie. Figma, Sketch, Photoshop, etc.), but this is not aligned with our concept of clicking directly into the content.

For these reasons, it might be prudent on our part to work the arrow icon back into the block regardless of the Top Toolbar mode preference as you indicated. We seem to have similar conclusions here. 😄

When a block is selected, always keep mover controls visible and displayed next to the selected block, even when the Top toolbar is active.

[mapk]

@joanrho If we go with the "show the movers next to the block regardless of top bar mode" than I think your last mockups are on the right track.

Rather than displaying them in the vertical middle of the block, how would it look if we showed them where they exist when hovering over the toolbar. Is that too far from the block? Maybe this position would work well with Select mode too?

[joanrho]

Thanks for the feedback, @mapk! Agree that the vertical centering of the movers felt a bit off (and could possibly get lost for very large/long blocks). Here are two updated directions:

1. What the movers could look like with the top toolbar active/inactive using the current mover (arrows only). This seems to be the path of least resistance given where things stand currently. However, the lack of grip handle doesn't help users know that the arrows can be clicked and dragged.
2. What the movers could look like with the top toolbar active/inactive using the former direction that included the grip handle. IMO, this is would be a better next step that can possibly take us to the direction above once users get used to the new UI gradually.

Thoughts?

[mapk]

@joanrho, I think we'd be best to go with the current G2 movers without the drag icon.

In relation to your explorations, I have a few questions. Right now, if I were to be focused in a block, I don't see the border, but I do see the block's toolbar. It's only when I hover over the block's icon and movers do I see the blue border.

How does this work in relation to the movers icon being by itself? Do we make the blue border visible all the time when the block has focus? Or do we require that the user switch to the Select mode to move blocks around at all?

[joanrho]

@mapk The problem with the blue borders during Editing mode is that they're very distracting and, in the case of text editing, there's no padding to give it a bit of breathing room. I'd recommend only showing the blue borders when users hover over the mover controls or if the user is in Select mode and hiding the borders when the user is in Editing mode.

[mapk]

So looks like the movers take on the behavior of the block toolbar in Top Toolbar mode. So they are always visible when the block is selected and/or focused, but disappear when the content is being edited. Then reappear when the mouse moves.

Any other thoughts around this before we get this developed? cc @jasmussen @shaunandrews

[shaunandrews]

I don’t think we should put the movers outside of the toolbar so quickly after putting them there.

It seems to me that drag-and-drop should be able to trigger using the select tool, regardless of the location of the block toolbar.

[mapk]

It seems to me that drag-and-drop should be able to trigger using the select tool, regardless of the location of the block toolbar.

Are you suggesting the user be required to switch to the Select tool, and then would be able to grab the block from anywhere to drag it?

[jasmussen]

I don’t think we should put the movers outside of the toolbar so quickly after putting them there.

Very much agree. We've only just merged the change, it's not part of WordPress 5.4, and it's barely tested in the plugin. Before reverting any efforts, it's worth listing what works and what doesn't, otherwise we will repeat past mistakes.

• There's a single unified block toolbar. A single control for keyboard-users to tab into, and a single consistent place to look for block configuration.
• This unified toolbar is detached from the block, making it possible to bump against screen edges, enabling it to scale from mobile to constrained contexts.
• There's a visual reduction in UI which makes the editor less cognitively heavy, yet still affords bigger tap targets for the remaining buttons.
• By removing side-UI entirely, we eliminate the complicated silhouette and lateral overlap that caused issues in floated, wide, fullwide, mobile and constrained contexts.
• Blocks can be tiny! The "Instagram" block inside "Social Links" needs movers too. Unifying in the toolbar affords that, without changing the footprint of the block.
• The efforts to respect the footprint of the block rather than painting arbitrary borders outside the block has profoundly simplified the editor markup, benefiting themers and developers and reducing the cost of entry to a WYSIWYG experience. This should not be understated.

Any new mover design needs to work in this context:

Let's note the downsides:

• The movers (and implicitly, the drag handle) are far away and fiddly to get to when you want them.
• The drag handle in being top and left from the block itself, means the draggable clone is visually detached from where you're dragging.

Tangential to the mover control, drag and drop in the editor has not worked well for a long time. It's not clear where a block will land when you drag it, and the experience is anything from fluid. Aside from any G2 efforts, drag and drop needs fresh energy.

But getting drag and drop right, even just on a technical level, is a big effort that is going to take a while, and likely requires a rewrite.

So what are near term solutions to improving drag and drop? Some things we can try today:

• Longpress a block anywhere on the block to "lift it off the page" and drag it. An idea by @mtias
• Leverage the select tool we already have. When this tool is selected, you can comfortably click the entire draggable visible area of a block to drag it. @shaunandrews — your idea here is right on the money.

Both keep the benefits of the current unified toolbar, and does not preclude us thinking more about how to improve the mover control separately.

But to quote Douglas Adams don't panic. We want to get this right. Putting things on the side of the block has proven itself to not work.

Let's not do this again:

[mapk]

Losing the ability to drag and drop is a pretty significant regression. Currently in WP 5.4 without the Gutenberg plugin installed, with Top Toolbar mode on, there is no way to drag and drop blocks. Not being able to drag is a real drag right now. 😉

Any new mover design needs to work in this context:

@jasmussen, I don't think that particular context is considering the Top Toolbar mode where both the movers and the drag and drop ability is moved away from the block.

I totally agree about all the pros with the new G2 designs and really love the work involved, but this regression needs help.

Longpress a block anywhere on the block to "lift it off the page" and drag it. An idea by @mtias

Unfortunately, this won't work as mentioned above. #20078 (comment) A "long press" already occurs when a user wants to highlight text within a block. This interaction would conflict with any other "long press" in the block itself.

Leverage the select tool we already have. When this tool is selected, you can comfortably click the entire draggable visible area of a block to drag it.

Honestly, this feel like a compromised solution no better than allowing the drag and drop ability to remain next to the block during Top Toolbar mode. It's definitely not ideal. As a user who drags and drops, the extra step of switching to the Select mode feels like a penalty for choosing the Top Toolbar mode. Without Top Toolbar selected, I don't have to switch to Select mode to drag anything around.

I definitely want to reiterate that this issue is primarily concerned with the "drag and drop" ability and not so much about the block movers.

Aside from any G2 efforts, drag and drop needs fresh energy.

I agree, and created this issue a bit ago. #21391

[jasmussen]

I don't think that particular context is considering the Top Toolbar mode where both the movers and the drag and drop ability is moved away from the block.

These two should still work:

• Longpress a block anywhere on the block to "lift it off the page" and drag it.
• Leverage the select tool we already have. When this tool is selected, you can comfortably click the entire draggable visible area of a block to drag it.

For some reason I missed your feedback on the above two in your response to Joan, my apologies:

The first problem I see with this in the block editor is that this interaction may conflict with highlighting text in a block because they both require a long press while moving the cursor.

This would be press without moving the cursor for n seconds, and the pattern to mimic is from mobile interfaces where the longpress is very often used for this. It's an idea and it may very well not work, but it seems easy to prototype and then we'll know.

For these reasons, it might be prudent on our part to work the arrow icon back into the block regardless of the Top Toolbar mode preference as you indicated. We seem to have similar conclusions here. 😄

As I see it, the purpose of the top toolbar option, more than anything, is to keep the editing canvas as clean and minimalist as possible so that no controls obscure content. If we start adding back drag handles to the canvas itself when the top toolbar option is enabled, we muddle that principle. But just like the longpress it seems completely fine to explore this in a PR so we'll know for sure.

[mapk]

This would be press without moving the cursor for n seconds, and the pattern to mimic is from mobile interfaces where the longpress is very often used for this. It's an idea and it may very well not work, but it seems easy to prototype and then we'll know.

I sure hope a PR can help here. I totally get the mobile pattern. My only conflict is the long press pattern being used for two different interactions. Do you have an example of a mobile app that uses both a long press to drag and drop items AND offers a way to select text on the same element? I'm searching for some myself. I believe, and I'm stoked if a PR can prove me wrong, that the relationship between the two interactions will be too finicky for users. There are plenty of times, I'll click and hold before moving my cursor to select text.

To avoid this, most graphic applications (and also Trello) use two different states for these interactions. In Figma, I cannot select the text AND drag the element in the same mode. I have to click into the element to select the text... OR I just click and drag the element. Same with Trello.

As I see it, the purpose of the top toolbar option, more than anything, is to keep the editing canvas as clean and minimalist as possible so that no controls obscure content.

While I agree, I think we also need to consider the functional aspect of dragging and dropping. It's already a mess, as noted above. Adding more finicky interactions could lead to more frustrations for the sake of trying to follow hard rules. I'd hate to find ourselves in the all too familiar state of guess-clicking to perform certain interactions (similar to parent block selection). I still miss the dashed outline of parent blocks that made it evident where to click. 😢

Let's get a PR going that enables a long-press on blocks for dragging. @youknowriad can someone begin looking at this? @jasmussen do you think we'd need a visual after n seconds to indicate that the block is now in some sort of drag state? Maybe something like this?

[ZebulanStanphill]

I think long-press-to-drag is the most promising idea to explore, even with the possible conflicts with selecting inline text. The drag mode should only be enabled when the pointer is pressed, held for a certain amount of time, and never moved during that time. (If the mouse moves at all, we assume text selection is happening and the drag mode can never be initiated as long as the current press continues.)

We'll want to make the wait time for starting drag mode fast enough to not feel sluggish, but not so fast that it's difficult to start a text selection. If you don't know about the drag interaction, you should never run into it by accident.

On mobile, long-press interactions to drag something are accompanied by haptic feedback when the object is "detached" and ready to drag. But of course you can't vibrate a mouse or trackpad, so I agree that a visual indicator should be introduced to indicate when a block enters "drag mode".

[mtias]

I think we should start with adding tap-to-drag when in "selection" mode by default. Then it's a matter of engaging selection mode on long-press-without-moving as a heuristic.

In Selection mode:

• Click / Tap engages edit mode.
• Click / Tap and Drag moves the block.

We should make this also clear by showing drag handled on the block-type name when in selection mode.

[ZebulanStanphill]

Does it really make sense to add drag functionality to select/navigation mode? Especially if we're not adding up/down movers to that mode. It seems like it would be muddying what that mode is for. I don't see why we can't just add the long-press-without-moving interaction to the edit mode.

[mapk]

We should make this also clear by showing drag handled on the block-type name when in selection mode.

[myleshyson]

Hey I'm wondering where this currently stands? Our organization has over 2,000 editors who were trained to use the editor with the "Top Toolbar" option enabled by default. We don't restrict users from switching preferences, but most don't anyway and just stay with our default settings for them.

We currently are stuck on WordPress 5.3 in large part because of this issue. This is a pretty significant UI change and would require us to do a big communication effort to inform them of the change. Not only that, but we would have to field a ton of emails from frustrated users who all of a sudden couldn't drag blocks around like they used to.

For large organizations like ours that use WordPress regressions like this cause pretty big headaches. Is this currently being worked on and are there any plans to address this in upcoming Gutenberg releases?

[mcsf]

I know this isn't the solution you are looking for, but until there is a good enough design solution for the block movers, it is always good to remember that blocks can be cut, copied and pasted with conventional keyboard shortcuts:

• on macOS: Command+X, Command+C, Command+V
• on Windows: Ctrl+X, Ctrl+C, Ctrl+V

There is also the Move To action:

[KyleDavisDev]

It wasn't clear or intuitive that I could click and drag the mover control arrows (when they appeared) to drag and drop my selected block. Perhaps the tooltip text over that element needs to mention that, or we should bring back the drag handle to indicate that the element can be dragged and dropped.

Took me wayyy too long to find this. Thank you @joanrho ! I had no idea what to tell clients on why a feature had gone missing.

[rothschild86]

It wasn't clear or intuitive that I could click and drag the mover control arrows (when they appeared) to drag and drop my selected block. Perhaps the tooltip text over that element needs to mention that, or we should bring back the drag handle to indicate that the element can be dragged and dropped.

Took me wayyy too long to find this. Thank you @joanrho ! I had no idea what to tell clients on why a feature had gone missing.

Wow, had me completely stumped too 🤦‍♂️

[nick6352683]

Any advances with this issue?