Don't show tab preview unless mouse velocity is low enough (and decelerating?)

[BrendanEich]

Test plan

See #9887

Original issue description

Did you search for similar issues before submitting this one?

Yes. Related issues: #3113 #3149. Fixing this may relieve pressure on those, or not, TBD.

Describe the issue you encountered:

Tab previews are generally liked but most users I've talked to, but it's an unscientific sample and some users dislike them because they trigger too easily and cause flicker and distraction when moving the mouse over the tab bar.

Expected behavior:

When moving quickly enough, especially when accelerating away from the tab bar, no preview.

• Platform (Win7, 8, 10? macOS? Linux distro?):

All.

• Brave Version:

0.11.5

• Steps to reproduce:
  1. Open three tabs on three visually distinct pages.
  2. Mouse over the tabstrip quickly, make back and forth and ellipsoidal motions.
  3. See tab previews flicker quickly (too quickly to be useful).
• Screenshot if needed:
• Any related issues: Tab preview only with hotkey #3113 Increase hover-to-preview time for pinned tabs to match unpinned tabs' hover-to-preview time #3149

[BrendanEich]

Might want to treat v as vector and only preview if slow enough, decelerating, and aimed "into" tab by some simple criteria.

[lucidNTR]

alternative to improve behaviour would be to add an initial wait time before previews are shown, after the initial preview was shown hovering over different tabs does not have a wait time so you can find the desired tab faster. vivaldi (and probably opera) have a nice behaviour for this

[michalbe]

Whats the status of this issue? I can see there was some work done but no PR sent.

[bsclifton]

@michalbe I don't believe we have any solutions. If this is one you'd like to solve, please feel free to grab it 😄

[cezaraugusto]

after taking this for a while here's my findings:

1. Velocity should work differently for X and Y axis. Reason is that a user going left/right || right/left is more likely to want to preview tabs than a user going/coming from tab/webview to urlbar.
2. Based on 1, a speed of 0.025px/milliseconds seemed to be the golden number, but that regressed flickering tab issue. The reason is that mouse was still too slow to trigger vertical mouse changes.
3. Movement from bottom to top is slower than top to bottom -- tested with 3 different people, and velocity will drastically change between two, so they should also be treated separately. Maybe by tracking negative/positive values. To make it work I had to get rid of velocity and make use of speed (which is linear) for each axis. But the point is that mouse movement isn't linear. After questioning life's meaning I stopped to find better alternatives.
4. Acceleration wouldn't work because sometimes velocity can start at 0 speed. So if we track it by deceleration it would first need to accelerate then track reducing value. If we just skip 0 values the flickering tab issue would be undercovered since at that moment tab would be already unintentionally previewed.

The best solution I found is to track relatedTarget on mouseEnter and check which element mouse was before. This way we can easily know if user is going/coming to webview/urlbar (vertical axis) or just coming from another tab. I did this a long time ago (ca9e4f8) and is the current approach we have. What is missing is a better RegExp test match so it can track every possible element.

[cezaraugusto]

moving back to backlog in favor of #8860.