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

Bug: DevTools DOM highlighting gets stuck after a prolonged hover #17855

Open
gaearon opened this issue Jan 16, 2020 · 7 comments
Open

Bug: DevTools DOM highlighting gets stuck after a prolonged hover #17855

gaearon opened this issue Jan 16, 2020 · 7 comments

Comments

@gaearon
Copy link
Member

@gaearon gaearon commented Jan 16, 2020

Steps To Reproduce

  1. Hover a component in DevTools
  2. Keep hovering it for a second or so
  3. Quickly move the cursor out of the DevTools without hovering anything else

Expected: DOM highlighting goes away.
Actual: DOM highlighting gets stuck.

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Jan 17, 2020

An easier way to trigger this:

  1. Click to select an element in the Components tree
  2. Move your mouse outside of the DevTools
  3. Click up or down arrow

The highlight will now "stick" until you focus on something else in DevTools.

TBH this is expected behavior in my mind, because it matches what the browser's Elements panel does so long as a native element is either hovered or focused. 1

If we wanted to, we could enable auto-hiding after a couple of seconds by updating Tree...

const highlightNativeElement = useCallback(
(id: number) => {
const element = store.getElementByID(id);
const rendererID = store.getRendererIDForElement(id);
if (element !== null && rendererID !== null) {
bridge.send('highlightNativeElement', {
displayName: element.displayName,
hideAfterTimeout: false,
id,
openNativeElementsPanel: false,
rendererID,
scrollIntoView: false,
});
}
},
[store, bridge],
);

...to also pass hideAfterTimeout: true like SelectedElement does...

const highlightElement = useCallback(() => {
if (element !== null && inspectedElementID !== null) {
const rendererID = store.getRendererIDForElement(inspectedElementID);
if (rendererID !== null) {
bridge.send('highlightNativeElement', {
displayName: element.displayName,
hideAfterTimeout: true,
id: inspectedElementID,
openNativeElementsPanel: true,
rendererID,
scrollIntoView: true,
});
}
}
}, [bridge, element, inspectedElementID, store]);

1 One small but maybe important difference between the two is that the native elements panel doesn't seem to leave the "stuck" highlight on mouse out. Maybe it's more reliably detecting mouse leaving the entire developer tools bounds? Maybe we could do that better somehow?

@Kelbie
Copy link

@Kelbie Kelbie commented Jan 18, 2020

Whether its expected behavior or not the behavior between Firefox and Chrome is inconsistent since the highlighting doesn't get stuck on Firefox.

@gaearon
Copy link
Member Author

@gaearon gaearon commented Jan 28, 2020

One small but maybe important difference between the two is that the native elements panel doesn't seem to leave the "stuck" highlight on mouse out.

I'm not sure I understand — this is exactly what I filed the issue about. :-) So yes, I think it is an important difference. I'm hitting this issue every day.

@gaearon
Copy link
Member Author

@gaearon gaearon commented Jan 28, 2020

...to also pass hideAfterTimeout: true like SelectedElement does...

That sounds like it would always remove the highlighting after a few seconds. So it would solve this issue, but by making the other case worse. That doesn't seem like an acceptable solution to me.

Ideally, all I want is for highlighting to reliably be removed the very moment I put my cursor outside the DevTools. Just like the native one does.

I understand there are edge cases like "what if I keep using the keyboard" but I'm not hitting them all the time. By contrast, I am hitting this particular bug (inconsistently reset highlighting on mouseout) every day many times.

@gaearon
Copy link
Member Author

@gaearon gaearon commented Jan 28, 2020

I spent half an hour here and I don't have even a remote idea for why the event doesn't fire. Let's ask twitter. https://twitter.com/dan_abramov/status/1222178476817633282

@dotproto
Copy link

@dotproto dotproto commented Jan 29, 2020

I mentioned this on Twitter, but I dug through devtools source to figure out how they were handling mouse movement & highlighting DOM elements.

It looks like the main place devtools updates the hover state is in their _onmousemove handler. This function in turn calls _highlightTreeElement which, interestingly, isn't referenced by any other event handler.

A few other methods (_onfocusout, _onmouseleave, _ondragstart, and _reset) call SDK.OverlayModel.hideDOMNodeHighlight() which, as the name implies, removes the highlight from the main page.

EDIT: Forgot to mention that I wanted to call out the different set of event handlers as the current implementation of itemData appears to bind to onMouseMove and onMouseLeave at the moment. The extra events devtools observes may also make things a bit more robust should dragging or more focus change handling be a concern for you.

@danielo515
Copy link

@danielo515 danielo515 commented Mar 16, 2021

This is a very annoying problem. Is there any way that I con "clear" it? many times it gets stuck when I switch between react developer tools and the elements tab

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants