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

Nav in Inspector - Does not consider mouse cursor when shrinking(child). Tooltip with item description ruins navigation #443

Closed
lukaszpolowczyk opened this issue Sep 18, 2022 · 6 comments · Fixed by #445
Labels
bug Something isn't working

Comments

@lukaszpolowczyk
Copy link

Describe the bug

Nav in Inspector - does not consider mouse cursor when shrinking(child).

Tooltip with item description ruins navigation.

Reproduction

When I press keyNav child, it should select the 2 symbol, but it selects the u symbol:

child.mp4

It looks like it doesn't check where the mouse cursor is.
It should reduce to the symbol u.

Conclusion: The inspector should take into account the place indicated by the mouse cursor.


When I press keyNav prev, moves, but only one step, then disappears, then returns to the starting point. It loops.
This problem does not exist with keyNav next - you can see it in the video, too.

prev.mp4

Although actually, with keyNav next is also this problem, it is a problem both with next and with prev:

prev2.mp4

Conclusion: The tooltip is to blame, with the item description. He is messing something up.
You can see it more in this prev2 recording.

Logs

No response

System Info

System:
    OS: Linux 5.10 Arch Linux
    CPU: (4) x64 AMD Athlon(tm) X4 950 Quad Core Processor
    Memory: 10.45 GB / 15.07 GB
    Container: Yes
    Shell: 5.1.8 - /bin/bash
  Binaries:
    Node: 18.4.0 - ~/.nvm/versions/node/v18.4.0/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 8.12.1 - ~/.nvm/versions/node/v18.4.0/bin/npm
  Browsers:
    Brave Browser: 100.1.37.109
    Firefox: 102.2.0esr
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.75 
    @sveltejs/kit: next => 1.0.0-next.484 
    svelte: ^3.44.0 => 3.50.1 
    vite: ^3.1.0-beta.1 => 3.1.2

Severity

annoyance

@lukaszpolowczyk lukaszpolowczyk added bug Something isn't working triage Awaiting triage by a project member labels Sep 18, 2022
@dominikg
Copy link
Member

The child nav selects the first child, regardless of cursor pos.

Please share a repo and detailed instructions on how to reproduce the next/prev loop.

@lukaszpolowczyk
Copy link
Author

The child nav selects the first child, regardless of cursor pos.

@dominikg Yes, I understand. And I would like it to work differently.
When I made the proposal for this function, I definitely had something else in mind.

You can see that this is a problem, because instead of selecting 2, it selects u, which is a different element.

Nav child should select the element indicated by the cursor, only which is deeper in the DOM tree.
That would be convenient and correct.


repo - https://github.com/lukaszpolowczyk/nav-loop

  1. you click #svelte-inspector-toggle
  2. you hover the mouse cursor over the second or further element with the content "aaaaaaaaaaaaaaaaaaaaaaaa", near its left edge
  3. you press LeftArrow on your computer keyboard once, and then a second time, and then a third time
    You'll see the Inspector's red selection move up, then disappear, then return to its starting point. This can be repeated indefinitely, in a loop

What you can see: The tooltip #svelte-inspector-host > .svelte-inspector-overlay, which is part of the inspector, moves so that the mouse cursor starts pointing at the tooltip. That's when the selection disappears, and then it loops.

Adding pointer-events: none; to the #svelte-inspector-host > .svelte-inspector-overlay element helps, but I don't know if that's the best solution.
Perhaps it is better that this tooltip never moves to the place of the mouse cursor? Because it's better that this tooltip is never obstructed by the mouse cursor.

It is important that the elements with the content "aaaaaaaaaaaaaaaaaaaaaaaa" have a pretty small width. If they had a very large one, and the mouse cursor was at its right edge, the tooltip jumps to another place, and the looping doesn't happen.
The problem is when there is little space, and the tooltip doesn't know where to place itself when navigating.

@dominikg
Copy link
Member

hmmm... the bubble should not be selectable already due to it living in node_modules. Maybe is_selectable needs to be improved.
child under cursor not being first-child only happens with multiple siblings that are not hoverable, right? Otherwise moving the cursor should have already selected the innermost element

@lukaszpolowczyk
Copy link
Author

hmmm... the bubble should not be selectable already due to it living in node_modules. Maybe is_selectable needs to be improved.

@dominikg I don't know which module it is exactly. You either need to add pointer-events: none; to the #svelte-inspector-host > .svelte-inspector-overlay, or make it so that this bubble never appears where the mouse cursor is.
I don't know more precisely.

child under cursor not being first-child only happens with multiple siblings that are not hoverable, right?

@dominikg Well, I don't know. This is how it always behaves.
All elements should be hoverable.

I don't know if it helps, but you have the structure:

obraz

Actually, I think before the updates, you could hover over a single ListSymbol and ListRelation.

This is how it works when you expand and narrow the selection (I only use Nav child and parent, and move the cursor from time to time):

nav-child-parent.mp4

It seems to me that it should always decrease in the same direction, and it decreases far to another element.

@dominikg dominikg removed the triage Awaiting triage by a project member label Sep 19, 2022
@dominikg
Copy link
Member

see #445 that is going to prevent selecting any svelte-inspector element and also adds pointer-events=none to prevent mouseover at the bottom edge of the screen where the initial bubble placement could end up under the cursor.

regarding child-under-cursor vs first-child: i'm not sure that is solvable really as it depends on application style a lot and while first-child can be confusing initially, it is at least consistent.
I also expect the case of wanting to go inward after hovering to be rare compared to selecting a parent of a tightly wrapped child, so unless someone contributes a lean and consistent implementation for child-under-cursor, first-child is what the child key is going to use.

@lukaszpolowczyk
Copy link
Author

@dominik Just solving the next prev problem, should already be helpful.

If the child-under-cursor problem is too difficult, you can let it go for now.

Thanks for your work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants