Block Editor: Fix is-hovered event listener #28715
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jeyip
added
[Type] Bug
|
Size Change: +34 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
|
Well, this solves one issue, but introduces another 🙈 The desired effect in the Site Editor is that only the block being hovered has an outline. This does fix the weirdness where you can hover over a block and see an outline, then move the cursor within that same block and find that the outline disappears. (IE the navigation issue in #27296). But having all the parents exhibit an outline as well is confusing. |
Yeah -- I mentioned this earlier, but I wasn't entirely sure if this change made the experience better or worse. Thanks for clarifying the desired behavior -- I'll keep refining what I have here. 👍 |
jeyip
force-pushed
the
try/removing-is-hovered-state-on-mouse-leave
branch
from
1a4927a
to
02cd3f5
Compare
|
The PR should be a lot more in line with expected hover behavior. There are still some odds and ends to wrap up, like a strange runtime warning and the hover state of column blocks -- I'll look into them more tomorrow. |
jeyip
force-pushed
the
try/removing-is-hovered-state-on-mouse-leave
branch
2 times, most recently
from
cbb909d
to
bc94aea
Compare
Mouseleave and mouseout are similar but differ in that mouseleave does not bubble and mouseout does. This means that mouseleave is fired when the pointer has exited the element and all of its descendants, whereas mouseout is fired when the pointer leaves the element or leaves one of the element's descendants (even if the pointer is still within the element). We were running into issues where navigation link li tag is hovered classnames were being removed when hovering over the navigation link's text. Using mouseleave instead of mouseout resolves the problem
jeyip
force-pushed
the
try/removing-is-hovered-state-on-mouse-leave
branch
from
bc94aea
to
1ec9789
Compare
jeyip
requested review from
vindl,
david-szabo97,
Addison-Stavlo,
Copons and
mattwiebe
jeyip
force-pushed
the
try/removing-is-hovered-state-on-mouse-leave
branch
from
1ec9789
to
2fbcfb8
Compare
jeyip
force-pushed
the
try/removing-is-hovered-state-on-mouse-leave
branch
from
09086a0
to
083ff45
Compare
jeyip
changed the title
|
@jameskoster Ready for another round of testing 👍 |
|
Yesss! This is so much better :) It works exactly as expected from the design perspective. |
Copons
approved these changes
Feb 11, 2021
|
Thanks so much for working on this. I'm not sure if this is related at all, but in the site editor if you mouse over a spacer block, the gray blob is shown. See #28129 This doesn't work in the post editor. I could swear it used to, but I'm not convinced. But looking at it, it looks like the Spacer block does not have an |
|
Hi @jasmussen! I'll try debugging a little bit. |
|
@jasmussen I loaded this Gutenberg master commit, which does not include the hover event changes in this PR. It looks like the issue you're describing already existed in master :( I'll try and bisect the post editor space block problems before the end of the day. If not, I'll take a look sometime tomorrow or later this week. Did you happen to create a GH issue already? |
|
Thank you for looking. Don't spend an ocean of time on it, I did not mean to give you the blame for a feature, just figured it might be related. I'm happy to open a ticket instead and we can let anyone pick it up. |
Of course!
No worries at all. Thanks for taking the time to point out these issues -- they definitely detract from the quality of the user experience and are important to address. In any case, I was just planning to debug during pockets of free time. Hopefully it's a quick fix 🤞
I can take care of it 🙂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Potentially addresses #27296
We were seeing strange behavior when applying and removing the
is-hoveredclassI couldn't pinpoint the exact problem, but after lots of experimentation, the odd mouseover behavior seems to be the result of race conditions. Instead of assigning hover listeners a single time to each block, we were inadvertently reassigning them over and over again whenever we hovered a block. See the
isHoveredprop from line 60 of the code block below:gutenberg/packages/block-editor/src/components/block-list/use-block-props/use-is-hovered.js
Lines 36 to 60 in bd270f3
In practice, the flow of logic would look like this:
mouseoverevent listenermouseoutevent listener would be assigned as wellmouseoverevent listener would be assigned againmouseoutevent listener would be assignedI refactored the hover logic to ensure that hover event listeners are assigned once on initial load, and re-assigned only when
isOutlineModeandisNavigationModechangesHow has this been tested?
Screenshots
Before
After
Types of changes
Bug Fix
Checklist: