New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't allow to start dragging blocks if a lock all exists #7225

Merged
merged 3 commits into from Jun 26, 2018

Conversation

Projects
None yet
5 participants
@jorgefilipecosta
Member

jorgefilipecosta commented Jun 8, 2018

Description

Fixes: #7191
Part of a general polishing to get #6993.

If a template lock "all" exists, the block cannot be moved anywhere. In that case, we should not allow drag a block to start. In master we allow the block to dragged around, but it could not be dropped anywhere. This PR's avoids to drag&drop to start in this case.

How has this been tested?

I verified that if no locking exists the blocks can be dragged around.
If template locking = insert the block can be dragged around but not dropped anywhere. This is an existing bug, in this locking, it should be possible to move the block. This bug is going to be addressed in a different PR.
If template locking = all, it is not possible to start the drag& drop in a block.
Verify that if a template lock all exists hover and selects still work as expected.

@jorgefilipecosta jorgefilipecosta self-assigned this Jun 8, 2018

@jorgefilipecosta jorgefilipecosta changed the title from Don't allow to start dragging blocks if a locking lock all exists to Don't allow to start dragging blocks if a lock all exists Jun 8, 2018

@jorgefilipecosta jorgefilipecosta requested a review from WordPress/gutenberg-core Jun 11, 2018

@@ -646,6 +648,7 @@ const applyWithSelect = withSelect( ( select, { uid, rootUID } ) => {
initialPosition: getSelectedBlocksInitialCaretPosition(),
isEmptyDefaultBlock: block && isUnmodifiedDefaultBlock( block ),
isPreviousBlockADefaultEmptyBlock: previousBlock && isUnmodifiedDefaultBlock( previousBlock ),
templateLock,

This comment has been minimized.

@mtias

mtias Jun 13, 2018

Contributor

Should this just be isDraggable or isMovable?

@gziolo

This comment has been minimized.

Member

gziolo commented Jun 13, 2018

isMovable sounds better if you want to cover both mouse and keyboard actions

@jorgefilipecosta

This comment has been minimized.

Member

jorgefilipecosta commented Jun 13, 2018

Thank you for the feedback @mtias and @gziolo I added an isMovable prop.

@jorgefilipecosta jorgefilipecosta requested a review from WordPress/gutenberg-core Jun 18, 2018

@tofumatt

tofumatt requested changes Jun 18, 2018 edited

I think a few documentation tweaks would be good here.

Also, "draggable" isn't technically a word. Maybe we could do draggingAllowed, canDrag, or isAllowedToDrag or just anything else that wouldn't upset spellcheck 😉

Nevermind, I can see it's already the name of the component and I'm late to that party. Still, a few documentation tweaks requested 😅

- Type: `boolean`
- Required: No
- Default: `true`

This comment has been minimized.

@tofumatt

tofumatt Jun 18, 2018

Member

Double-space in here; could be single.

@@ -6,6 +6,14 @@
The component accepts the following props:
### draggable
If the component is in a draggable state or not. If false, the component is rendered but it is not possible to drag it. Defaults to true.

This comment has been minimized.

@tofumatt

tofumatt Jun 18, 2018

Member

"If the component is in a draggable state or not." is a bit confusing, I think the point of this is to set the "dragability" of the block, right? Would this be better as:

### draggable

Allow the component to be dragged in the editor; defaults to `true`. If `false`, the component is rendered but it is not possible to drag the component.

This comment has been minimized.

@gziolo

gziolo Jun 18, 2018

Member

Agreed, it's very confusing that Draggable component can't be draggable in some circumstances. Ideally, it shouldn't be rendered at all when it is not draggable.

@@ -502,6 +503,7 @@ export class BlockListBlock extends Component {
onDragEnd={ this.onDragEnd }
isDragging={ dragging }
elementId={ blockElementId }
draggable={ isMovable } // only in locking all moving blocks is totally impossible

This comment has been minimized.

@tofumatt

tofumatt Jun 18, 2018

Member

What does this comment mean? I don't quite understand it.

This comment has been minimized.

@gziolo

gziolo Jun 18, 2018

Member

Is there any particular reason why we can't perform the check for isMovable outside of the component?

{ ! isMultiSelected && (
    <BlockDraggable
        ...
    />
) }

We already have a precedence here, what is blocking us from adding another check in addition to isMultiSelected?

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta Jun 18, 2018

Member

The main reason is that we depend on the styles set by BlockDraggable. Without BlockDraggable being rendered, it becomes almost impossible to get the delete and ellipsis buttons to appear. When multi-selecting it is not a problem because they appear there all the time even if the mouse is not close to the blocks.
I will try to apply a refactor to the styles.

This comment has been minimized.

@gziolo

gziolo Jun 18, 2018

Member

I will try to apply a refactor to the styles.

That would be awesome, thanks for looking into it 👍

@jorgefilipecosta

This comment has been minimized.

Member

jorgefilipecosta commented Jun 22, 2018

Hi @gziolo, @tofumatt I applied your suggestions, and now this PR does not change any existing component. BlockDraggable is rendered when in fact we can move the block.

In order to make not rendering BlockDraggable possible, a CSS rule was added that makes blocks hover and select area not dependent on BlockDraggable being present.

@gziolo gziolo added this to the 3.2 milestone Jun 25, 2018

@tofumatt

I'm not sure what these comments mean. If they could be clarified the code looks good; I just don't know about the comments.

.editor-block-list__block {
@include break-small {
// use a wider available space for hovering/selecting on top level blocks

This comment has been minimized.

@tofumatt

tofumatt Jun 26, 2018

Member

These should use capital "U" and have a period at the end of the sentence 🙂

This comment has been minimized.

@tofumatt

tofumatt Jun 26, 2018

Member

That said, I'm not sure what this (or the comment below) mean.

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta Jun 26, 2018

Member

Hi, @tofumatt thank you for your review. I updated the comments, let me know if you find the new version of the comments more helpful :)

jorgefilipecosta and others added some commits Jun 8, 2018

@tofumatt

Looks good!

The new comments totally explain it! There were some whitespace issues and I tweaked the comments. If they look good to you merge away 😄

@jorgefilipecosta jorgefilipecosta merged commit d316177 into master Jun 26, 2018

2 checks passed

codecov/project 46.77% remains the same compared to 8fa8b64
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jorgefilipecosta jorgefilipecosta deleted the fix/dont-allow-drag-start-if-template-lock-exists branch Jun 26, 2018

&:before {
bottom: 0;
content: '';
left: -$parent-block-padding - $block-padding;

This comment has been minimized.

@jasmussen

jasmussen Jun 28, 2018

Contributor

I really appreciate you making this change, and the intent behind it.

It introduced a small regression, though, as it makes a horizontal scrollbar appear when a block is full-wide.

I discovered this while rebasing #7365. I will implement a fix in that branch, perhaps you can help me review it so we can get it in faster? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment