-
Notifications
You must be signed in to change notification settings - Fork 971
make tab previews based on mouse idle time #9887
Conversation
|
||
class Tab extends React.Component { | ||
constructor (props) { | ||
super(props) | ||
this.onMouseMove = this.onMouseMove.bind(this) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bridiver before sending this I debounced mouse move but even with 10ms it was leading to bad behavior and tabs were previewing without user action, given they were debounced. The event triggered inside onmousemove is canceled with both mouseenter and mouseleave, which I guess cover the event's cost.
app/renderer/components/tabs/tab.js
Outdated
// previewMode is only triggered if mouse is idle over a tab | ||
// for a given amount of time based on timing defined in prefs->tabs | ||
clearTimeout(this.mouseTimeout) | ||
this.mouseTimeout = setTimeout(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bridiver I had a hard time moving the delayed state update to frameStateUtil while trying to keep using setTabHoverState (without adding extra actions).
afaict there's no way to delay state updates without calling an action inside the utils file? Even if so I guess per our convo we are trying to avoid that. If this is not unacceptable I would prefer to leave it as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we definitely don't want to add a timeout here because we handle that in frameStateUtil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the best thing to do here is add a onTabMouseMoved
action
* | ||
* @param {Object} frameKey - the frame key for the webview in question. | ||
*/ | ||
setPreviewFrame: function (frameKey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't use it anymore. frameStateUtilsetPreviewFrameKey(..args)
now checks for preview mode and returns if there is none. I guess the only use case for that was to delay tab previews for one use case, which we don't have anymore
app/renderer/lib/tabUtil.js
Outdated
@@ -36,3 +36,8 @@ module.exports.hasBreakpoint = (breakpoint, arr) => { | |||
arr = Array.isArray(arr) ? arr : [arr] | |||
return arr.includes(breakpoint) | |||
} | |||
|
|||
module.exports.hasTabAsRelatedTarget = (event) => { | |||
const tabComponents = /tab(?=_|area|title|id)|closetab|icon/i |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems fragile to me, we should probably be checking for children with something like https://stackoverflow.com/questions/4697758/prevent-onmouseout-when-hovering-child-element-of-the-parent-absolute-div-withou
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up checking for parentNode
instead + nulling pointer events for elements I don't want to be triggered. That method is now tested too.
needs fixes and rebase so I'm going to move to 0.19.x |
4e49938
to
95d61a2
Compare
ok rebased + more tests added, ready for re review |
95d61a2
to
a7e9925
Compare
docs/state.md
Outdated
@@ -667,6 +667,8 @@ WindowStore | |||
hoverTabIndex: number, // index of the current hovered tab | |||
tabPageIndex: number, // index of the current tab page | |||
previewTabPageIndex: number // index of the tab being previewed | |||
previewTabPageIndex: number, // index of the tab being previewed | |||
previewMode: boolean // whether or not tab preview should be fired based on mouse idle time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you please sort this alphabetically?
- Auditors: @bridiver, @bsclifton - Fix #8860 - Fix #3271
14f7c04
to
764d310
Compare
moving to 0.20.x per triage meeting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works great! 😄
@bradleyrichter this PR is defaulting tab preview timing to long (which is very different than today's experience). Right now, we're closer to the Short
value. Do you think these timings are OK? (long=2 seconds, normal=1 second, short=1/2 second)
cc: @alexwykoff @bbondy
@bsclifton @cezaraugusto We should use Normal as the default. |
ok changed default to NORMAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice polish on this one 😄 👌
make tab previews based on mouse idle time
@cezaraugusto could you add an even shorter timing? The shortest time feel too slow, I want to have it as fast as it was before this pr 👎 Great job otherwise 👍 |
It was instant before and I liked that and I think many users liked that, maby a setting called "no delay"? |
@Jacalz I think that's something we should consider |
Any news about the no timing mode? I really hate having to wait for tab previews 👎 |
Agree! Let’s include an instant setting to retain the original feel.
We might want to consider using that setting for existing users who have previews enabled.
… On Jan 24, 2018, at 5:46 AM, Jacob ***@***.***> wrote:
Any news about the no timing mode? I really hate having to wait for tab previews 👎
Should I open an issue for it? 🙂
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
by now you can change to SHORT under prefs->tabs->time to wait before previewing a tab |
@Jacalz do you mind opening an issue for this? pls cc me in there let's do it |
Will do 👍 |
The short time is too long for me 😅 |
Opened the issue for you @cezaraugusto 👍 |
Submitter Checklist:
git rebase -i
to squash commits (if needed).Auditors: @bridiver
/cc @luixxiul for QA
Fix #8860
Fix #3271
Test Plan:
Previews are now happening based on mouse idle time. Which means that it will only be fired if you stay the mouse idle over a tab for a given amount of time -- which is defined in prefs->tabs.
The general test plan is to hover over a tab up to a point that the tab previews.
For further manual tests please refer to #8852 (comment)
Automated tests:
Reviewer Checklist:
Tests