Floated blocks don't get Move or Drag Controls #10300
Labels
[Feature] Drag and Drop
Drag and drop functionality when working with blocks
Needs Testing
Needs further testing to be confirmed.
Comments
designsimply
added
Needs Testing
|
I can confirm this bug. I tested with Chrome 69.0.3497.100 on MacOS 10.13.6 with fresh WordPress install (runs in docker setup of Gutenberg) and Twentyseventeen-theme. The same happens, if Cover Image Block is aligned left. Although Move-controls are visible, you can't really use them. If you try to use Move-controls, it will move paragraph-block instead of Cover Image -block |
|
This issue might have something to do with #4764 🤔 |
|
I was able to reproduce this too and even worst, I can only see the controls to move blocks for the central block:
|
|
This is intentional behaviour for floated blocks now, per #10085. |
|
That is absolutely ridiculous that you can't move an item that is right aligned, and it's even more ridiculous that you're no longer trying to fix the issue. |
|
@maddisondesigns No one ever said we weren't going to try to improve this. The fact is that drag and movement controls on floated blocks caused a lot of UI issues and we still hope we can solve those issues, especially in Phase 2 which will have a much bigger focus on block layout. We just have to prioritise other things right now especially for those of us who are volunteering and have limited hours to commit to the project. |
Pretty sure that's exactly what that says (from #10085). This bug is being justified for a ridiculous reason.
I totally understand that people like yourself who are volunteering have limited hours, and I really appreciate the work that you've put into this, but there are Automatticians who are getting paid to work on this, so trying to justify this bug purely because there are a bunch of other bugs that also need fixing, is irresponsible. What happened to the whole "This wont be merged until its ready" argument. Seems like nobody cares about that now and the priority is to simply get it in before WordCamp US, no matter the cost. |
designsimply
changed the title
|
Tested and confirmed using an image block (#11454). Updated the title to note it's not limited to Cover. Closing this one because it's a known issue, the missing movers are a temporary workaround, and there are plans to re-visit when more time is available to spend because it needs a special implementation. See #11454. I also wanted to say thank you for raising these kinds of issues! It's good to raise them and your feedback is definitely heard. |
jasmussen
pushed a commit
that referenced
this issue
Dec 10, 2018
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
pushed a commit
that referenced
this issue
Jan 30, 2019
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
pushed a commit
that referenced
this issue
Feb 5, 2019
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.
gziolo
pushed a commit
that referenced
this issue
Feb 6, 2019
* 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.
youknowriad
pushed a commit
that referenced
this issue
Mar 6, 2019
* 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.
youknowriad
pushed a commit
that referenced
this issue
Mar 6, 2019
* 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Normally when you select a block, the move controls and drag control show on the left of the block. When a Cover Image block is right aligned and then selected, no controls appear which means that it can no longer be moved.
Another issue is that when the cover image is left aligned, the controls appear, but it's incredibly difficult to move the block. Whenever you try to click and drag the using the drag control, the text block beneath it gets selected instead. Occasionally, if you're lucky and move the cursor fast enough, you can drag the Cover Image.
Vid: https://cl.ly/c65a76f434e5
To Reproduce
Steps to reproduce the behavior:
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: