Skip to content
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

[G2] Block mover is not clickable or draggable on full-width blocks #20451

Closed
jffng opened this issue Feb 25, 2020 · 6 comments · Fixed by #21097
Closed

[G2] Block mover is not clickable or draggable on full-width blocks #20451

jffng opened this issue Feb 25, 2020 · 6 comments · Fixed by #21097
Assignees
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@jffng
Copy link
Contributor

jffng commented Feb 25, 2020

Description
Following the amazing work from #19348, I encountered a small issue: the block mover isn't clickable or draggable on blocks that are set to full-width, e.g. the image, gallery, cover, group, and columns block. The mover appears and renders the correct contextual state, but just isn't clickable.

It appears to be a stacking order issue; I briefly tested manually adding a positive z-index to any of the container elements (e.g. .block-editor-block-toolbar__mover-switcher-container), and this allowed the mover to be clickable + draggable.

Screen Shot 2020-02-25 at 5 24 08 PM

To reproduce

  1. Install Gutenberg 7.6.0-rc.1
  2. Open up a post and add any block that accepts full-width
  3. Try to move the block using the mover UI

Environment

  • Gutenberg 7.6.0-rc.1
  • WordPress 5.3.2
  • Browser: chrome, firefox
  • OS: macOS 10.14.5
@SchneiderSam
Copy link

SchneiderSam commented Feb 26, 2020

Yes same here

@jasmussen

@jasmussen jasmussen added the [Type] Bug An existing feature does not function as intended label Feb 26, 2020
@jasmussen
Copy link
Contributor

CC: @youknowriad do you have any insights on how to address this?

@youknowriad
Copy link
Contributor

Nothing in particular, seems more like a z-index issue. I also wonder why it's just in full width, so maybe more a CSS to remove somewhere.

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Mar 12, 2020
@youknowriad youknowriad removed their assignment Mar 13, 2020
@youknowriad youknowriad removed the [Status] In Progress Tracking issues with work in progress label Mar 13, 2020
@lgersman
Copy link

Nothing in particular, seems more like a z-index issue. I also wonder why it's just in full width, so maybe more a CSS to remove somewhere.

Yeah,

@media (min-width: 782px) {
    .block-editor-block-toolbar.has-responsive-movers
      .block-editor-block-toolbar__mover-trigger-container {
      z-index: inherit;
    }
  }

seems to fix this issue.

@youknowriad
Copy link
Contributor

@lgersman I'm not sure I understand that fix yet but please consider opening a PR :)

jasmussen added a commit that referenced this issue Mar 24, 2020
Fixes #20451. Props @lgersman for advice.

The mover control did not work for full-wide images. I'm honestly surprised it worked in wide and normal settings, because the z-index was -1 meaning it shouldn't be. I suspect it's because the layout canvas has padding left and right that somehow interferes with things here, but couldn't verify.

However the negative z index wasn't a good fix in the first place. The reason it was there, was to make sure that when the mover control animates out, it appears to be coming from "beneath" the block toolbar. The z-index put it below the entire block toolbar, which is the container that has a background color.

This PR changes things so the mover control does not have a z-index, but the switcher button has been elevated, and been given a white background color to cover it.
@jasmussen
Copy link
Contributor

I created a fix in #21097.

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Mar 24, 2020
jasmussen added a commit that referenced this issue Mar 27, 2020
Fixes #20451. Props @lgersman for advice.

The mover control did not work for full-wide images. I'm honestly surprised it worked in wide and normal settings, because the z-index was -1 meaning it shouldn't be. I suspect it's because the layout canvas has padding left and right that somehow interferes with things here, but couldn't verify.

However the negative z index wasn't a good fix in the first place. The reason it was there, was to make sure that when the mover control animates out, it appears to be coming from "beneath" the block toolbar. The z-index put it below the entire block toolbar, which is the container that has a background color.

This PR changes things so the mover control does not have a z-index, but the switcher button has been elevated, and been given a white background color to cover it.
jasmussen added a commit that referenced this issue Mar 27, 2020
Fixes #20451. Props @lgersman for advice.

The mover control did not work for full-wide images. I'm honestly surprised it worked in wide and normal settings, because the z-index was -1 meaning it shouldn't be. I suspect it's because the layout canvas has padding left and right that somehow interferes with things here, but couldn't verify.

However the negative z index wasn't a good fix in the first place. The reason it was there, was to make sure that when the mover control animates out, it appears to be coming from "beneath" the block toolbar. The z-index put it below the entire block toolbar, which is the container that has a background color.

This PR changes things so the mover control does not have a z-index, but the switcher button has been elevated, and been given a white background color to cover it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants