Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

make tab previews based on mouse idle time #9887

Merged
merged 2 commits into from
Aug 15, 2017
Merged

Conversation

cezaraugusto
Copy link
Contributor

@cezaraugusto cezaraugusto commented Jul 6, 2017

Submitter Checklist:

  • Submitted a ticket for my issue if one did not already exist.
  • Used Github auto-closing keywords in the commit message.
  • Added/updated tests for this change (for new code or code which already has tests).
  • Ran git rebase -i to squash commits (if needed).
  • Tagged reviewers and labelled the pull request as 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.

  1. Switching to another tab should preview the tab;
  2. Moving out of a tab should cancel preview;
  3. After each tab leave you will have to wait for the timeout to happen again, so you can preview

For further manual tests please refer to #8852 (comment)

Automated tests:

npm run test -- --grep="webview previews the next tab when current hovered tab is closed"
npm run test -- --grep="webview previews when tab is hovered"
npm run test -- --grep="TabsTab component"
npm run test -- --grep="tabUtil hasTabAsRelatedTarget"

Reviewer Checklist:

Tests

  • Adequate test coverage exists to prevent regressions
  • Tests should be independent and work correctly when run individually or as a suite ref
  • New files have MPL2 license header

@cezaraugusto cezaraugusto added this to the 0.18.x (Beta Channel) milestone Jul 6, 2017
@cezaraugusto cezaraugusto self-assigned this Jul 6, 2017

class Tab extends React.Component {
constructor (props) {
super(props)
this.onMouseMove = this.onMouseMove.bind(this)
Copy link
Contributor Author

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.

// 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(() => {
Copy link
Contributor Author

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.

Copy link
Collaborator

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

Copy link
Collaborator

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) {
Copy link
Contributor Author

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

@@ -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
Copy link
Collaborator

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

Copy link
Contributor Author

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.

@bbondy bbondy modified the milestones: 0.19.x (Beta Channel), 0.18.x (Release Channel) Jul 13, 2017
@bbondy
Copy link
Member

bbondy commented Jul 13, 2017

needs fixes and rebase so I'm going to move to 0.19.x

@cezaraugusto cezaraugusto requested review from bridiver and removed request for luixxiul and bridiver July 24, 2017 22:38
@cezaraugusto cezaraugusto force-pushed the tabsbar--preview-timing branch 2 times, most recently from 4e49938 to 95d61a2 Compare July 25, 2017 03:42
@brave brave deleted a comment from codecov-io Jul 25, 2017
@cezaraugusto
Copy link
Contributor Author

ok rebased + more tests added, ready for re review

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
Copy link
Contributor

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?

@cezaraugusto
Copy link
Contributor Author

moving to 0.20.x per triage meeting

@cezaraugusto cezaraugusto modified the milestones: 0.20.x (Developer Channel), 0.21.x (Nightly Channel) Aug 8, 2017
Copy link
Member

@bsclifton bsclifton left a 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

@bradleyrichter
Copy link
Contributor

@bsclifton @cezaraugusto We should use Normal as the default.

@cezaraugusto
Copy link
Contributor Author

ok changed default to NORMAL

Copy link
Member

@bsclifton bsclifton left a 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 😄 👌

@bsclifton bsclifton merged commit 1deb581 into master Aug 15, 2017
@bsclifton bsclifton deleted the tabsbar--preview-timing branch August 15, 2017 06:21
bsclifton added a commit that referenced this pull request Aug 15, 2017
make tab previews based on mouse idle time
@Jacalz
Copy link
Contributor

Jacalz commented Aug 17, 2017

@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 👍

@Jacalz
Copy link
Contributor

Jacalz commented Aug 17, 2017

It was instant before and I liked that and I think many users liked that, maby a setting called "no delay"?

@cezaraugusto
Copy link
Contributor Author

@Jacalz I think that's something we should consider

cc @bradleyrichter

@Jacalz
Copy link
Contributor

Jacalz commented Jan 24, 2018

Any news about the no timing mode? I really hate having to wait for tab previews 👎
Should I open an issue for it? 🙂

@bradleyrichter
Copy link
Contributor

bradleyrichter commented Jan 24, 2018 via email

@cezaraugusto
Copy link
Contributor Author

cezaraugusto commented Jan 24, 2018

by now you can change to SHORT under prefs->tabs->time to wait before previewing a tab

@cezaraugusto
Copy link
Contributor Author

@Jacalz do you mind opening an issue for this? pls cc me in there let's do it

@Jacalz
Copy link
Contributor

Jacalz commented Jan 24, 2018

Will do 👍

@Jacalz
Copy link
Contributor

Jacalz commented Jan 24, 2018

The short time is too long for me 😅

@Jacalz
Copy link
Contributor

Jacalz commented Jan 24, 2018

Opened the issue for you @cezaraugusto 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants