Block mover hidden when left or right aligned #12736

michealengland · 2018-12-09T20:53:26Z

Describe the bug
Left or right aligned blocks may have hidden move controls if it floated. This looks intentionally added in #10085.

Could be related to #12290

To Reproduce
Steps to reproduce the behavior:

Create a pull quote block.
Left or right align the pull quote block.
Attempt to drag or move the pull quote block.

Expected behavior
Expected the mover controls to be visible when hovering over the pull quote block.

Screenshots
If applicable, add screenshots to help explain your problem.

Initial Investigation

While a non floated block pull-quote has a class="editor-block-mover is-visible" the block controls display as expected.
While a pull quote block is floated left or right and has class="editor-block-mover is-visible" the block move controls are hidden. This is caused by an overflow on the parent container.

//editor/style.css line 349
.editor-block-list__layout .editor-block-list__block[data-align="left"] .editor-block-mover, .editor-block-list__layout .editor-block-list__block[data-align="left"] .editor-block-list__block-mobile-toolbar, .editor-block-list__layout .editor-block-list__block[data-align="right"] .editor-block-mover, .editor-block-list__layout .editor-block-list__block[data-align="right"] .editor-block-list__block-mobile-toolbar {
    display: none;
}

Turning off display none will display the block menu controls. However, the controls disappear while visible for the paragraph block that the pull quote is floated around.

You can get the block working properly again by changing left: -30px to `left: 0;'. However, the movement controls will display in an awkward place.

.editor-block-list__block > .editor-block-mover {
    padding-right: 2px;
    // left: -30px;
    left: 0; // moves the block back in the container.
    display: none;
}

The text was updated successfully, but these errors were encountered:

gwwar · 2018-12-09T21:27:03Z

@jasmussen sounds like we may need to revisit the UI for these cases. Any chance we could get some design help for what should happen.

jasmussen · 2018-12-10T10:26:38Z

Hi there, thanks for the ticket and suggestions. I can understand how this feels like a bug, but for the time being the fact that the block mover is hidden on floats is not a bug but hidden because, as you suggest itself in the ticket, the experience is not good.

Essentially the problem is that on a left-floated block, the block mover for the float will overlap with the block mover for the text that wraps it.

We're definitely still thinking about how to fix this. Most recently I experimented in a branch (try/movers-below-floats-wide) where I positioned the block mover below the selected block. But this conflicted with captions. In other words, the problem is not a lack of desire to fix it but the lack of a good solution to what happens to the block mover on a float.

This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me.

jasmussen · 2018-12-10T11:44:22Z

I created #12758 as yet another experiment to restore the block mover for floats. But I'm still not sure that's successful. Let me know any thoughts you might have.

This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me.

@ZebulanStanphill

* Try: Restore block mover for floats. This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me. * Address feedback, and improve dragging edgecase. This addresses comment feedback by @ZebulanStanphill, thanks, and it also hides the block mover from the ghost when you are dragging. * Add borders around floats.

@ZebulanStanphill

* Try: Restore block mover for floats. This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me. * Address feedback, and improve dragging edgecase. This addresses comment feedback by @ZebulanStanphill, thanks, and it also hides the block mover from the ghost when you are dragging. * Add borders around floats.

@ZebulanStanphill

* Try: Restore block mover for floats. This PR hopes to fix #12736, #11424, #10300. Currently we hide the block mover for any floated block. We do this because if you have a left floated image followed by a paragraph, the block mover for the image would overlap exactly with the block mover for the subsequent paragraph block. This would cause moving a float to be fiddly and virtually impossible as the hover states for the two conflicted. This PR is an experiment to mitigate, or possibly fix that. It's a try branch because it is not necessarily a solid fix. What this PR does: - It makes it so the block mover cannot be invoked when only hovering a float, but when the float is selected they are permanently visible. - It changes some z-indexes so floats always have a higher z-index than not a float. - It changes the footprint of the side-UI container to "cover up" the underlying paragraph block, so it won't invoke unlesss you move the mouse below the footprint. This is best explained in some GIFs. The reason this is a "Try" branch is that when you move the mouse over the adjacent paragraph, the block mover is show as overlapping the selected floats block mover. But due to the rearranging of z-indexes, at least this is only a visual issue. A click on the floats block mover will still work as intended. Why can't the float have on-hover block movers like every other block, you ask? Picture again the test-case of a left floated image followed by a paragraph of text. In this case, hovering over the image would show a block mover that would visually appear to be that of the paragraph block. By showing it when the float is selected, the context is clear. We could experiment with not showing the hover block mover for float-adjacent blocks when hovered, but this isn't feasible because you might have a float, and then a block that clears this float, in which case the rule would break down. Lay your thoughts on me. * Address feedback, and improve dragging edgecase. This addresses comment feedback by @ZebulanStanphill, thanks, and it also hides the block mover from the ghost when you are dragging. * Add borders around floats.

gwwar added the [Type] Bug An existing feature does not function as intended label Dec 9, 2018

jasmussen mentioned this issue Dec 10, 2018

Try: Restore block mover for floats. #12758

Merged

youknowriad mentioned this issue Jan 15, 2019

Left/right aligned images not movable #13330

Closed

gziolo closed this as completed in #12758 Feb 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block mover hidden when left or right aligned #12736

Block mover hidden when left or right aligned #12736

michealengland commented Dec 9, 2018 •

edited

Loading

gwwar commented Dec 9, 2018

jasmussen commented Dec 10, 2018

jasmussen commented Dec 10, 2018

Block mover hidden when left or right aligned #12736

Block mover hidden when left or right aligned #12736

Comments

michealengland commented Dec 9, 2018 • edited Loading

Initial Investigation

gwwar commented Dec 9, 2018

jasmussen commented Dec 10, 2018

jasmussen commented Dec 10, 2018

michealengland commented Dec 9, 2018 •

edited

Loading