search

matchu / Strict-Workflow

A Chrome extension that helps you stay focused by blocking sites during work timers and letting you browse during break timers
https://chrome.google.com/webstore/detail/cgmnfnmlficgeijcalkgnnkigkefkbhd
Other
193 stars 98 forks source link

Block any tabs which were opened by tab from the blocked list. #13

Open benbest86 opened 12 years ago

benbest86 commented 12 years ago

My biggest time sink is Hacker News (link aggregator similar to reddit), so it's easy to put that on a blocked list. Unfortunately I tend to open three or four tabs from there at a time, which are not blocked by the plugin as they are from all sorts of domains.

The Chrome extension API can get you the id of the tab which opened another tab, so it is easy to work this out during the block phase if the tab to be blocked is still open. Where things get messier is knowing which tabs to unblock once a break starts. You can do the same check on the parent tab, but if the URL of the parent has changed or the parent has been closed, then there is no way to tell. This can be hacked around by storing which tabs are currently blocked, which would require either a global variable or a bit of refactoring in the code the way it is now.

I'll probably implement this in my own fork as it will make the plugin significantly more useful for me, so let me know if you're interested in working it in, and if so if you have a preference for a quicker hack, or a bigger refactoring. There are probably a bunch of ways to go about it and I'm both new to chrome extension development and not sure how you might prefer to do it.

Thanks so much for all the initial work you've done on this! Been very helpful in the past few weeks.

matchu commented 12 years ago

Interesting thought. I like the concept, but feel like it might end up being difficult to determine intent. For example, consider the following scenarios:

Anyway, you see where I'm going with this. In order to truly be useful, we'd need to block more than just the very first page launched from the blacklisted tab, but that could easily result in far too many false positives. Blocking only the first pageload in the new tab might be an acceptable compromise, but then we'd hit issues with, say, sites that do that weird full-page ad then redirect after a few seconds, or even a simple refresh. What are your thoughts on that?

Anywho, as far as implementation goes, shouldn't be too bad: when we block a tab, keep its ID in a property of the Pomodoro object. When we close a tab, remove its ID from that list if present so we don't collect a bunch of stale data.

So yeah. Fork away, and let me know when it's all set :D Whether or not I pull it in as a standard options checkbox will likely depend on how easy the feature is to explain (can I fit it in the one-line checkbox label?) and whether we reach a super-satisfying answer on how to handle subsequent page loads in children of blocked tabs. Thanks, bro!

benbest86 commented 12 years ago

Agreed on the challenges of the use cases. I almost never reuse tabs (will usually just open a new one) so I'm ok with either of the implementation options (block all tabs whose parents are blocked, or just the first page load). The UI issue is also an interesting one and will definitely take some thought.

Thanks, and will send you the fork when it's ready!

On Mon, Jun 11, 2012 at 5:26 PM, matchu < reply@reply.github.com

wrote:

Interesting thought. I like the concept, but feel like it might end up being difficult to determine intent. For example, consider the following scenarios:

  • From Hacker News I pull up an Al Jazeera link in a new tab. Then, I follow a link to another Al Jazeera article, either in the same tab or a new tab. This should probably be blocked.
  • From Hacker News I pull up an Al Jazeera link in a new tab. Then, I follow a link to a related CNN article, either in the same tab or a new tab. This should probably be blocked.
  • From Hacker News I pull up an Al Jazeera link in a new tab. Then, intrigued by the subject, I use the tab's search bar to search for related articles, then open them in either the same tab or a new tab. This should probably be blocked.
  • From Hacker News I pull up an Al Jazeera link in a new tab. Then, intrigued by the subject, I use the tab's search bar to search for related articles, then end up on Wikipedia. After reading the Wikipedia article, I'm bored of the subject, so decide to use Wikipedia's search bar to search for an article related to the actual productive work I should be doing. This probably should not be blocked.
  • From Hacker News I pull up an Al Jazeera link in a new tab. Then, no longer interested in this tab, I decide to use it for other purposes by entering an unrelated search query, clicking the home button, clicking the Google Mail Checker button, whatever. This definitely should not be blocked.

Anyway, you see where I'm going with this. In order to truly be useful, we'd need to block more than just the very first page launched from the blacklisted tab, but that could easily result in far too many false positives. Blocking only the first pageload in the new tab might be an acceptable compromise, but then we'd hit issues with, say, sites that do that weird full-page ad then redirect after a few seconds, or even a simple refresh. What are your thoughts on that?

Anywho, as far as implementation goes, shouldn't be too bad: when we block a tab, keep its ID in a property of the Pomodoro object. When we close a tab, remove its ID from that list if present so we don't collect a bunch of stale data.

So yeah. Fork away, and let me know when it's all set :D Whether or not I pull it in as a standard options checkbox will likely depend on how easy the feature is to explain (can I fit it in the one-line checkbox label?) and whether we reach a super-satisfying answer on how to handle subsequent page loads in children of blocked tabs. Thanks, bro!

Reply to this email directly or view it on GitHub: https://github.com/matchu/Strict-Pomodoro/issues/13#issuecomment-6250628

Dave314159 commented 11 years ago

One way to address the false-positives would be to visually distinguish tabs that will be blocked when the work phase begins, and put a check-box in the tab context menu allowing the user to remove a tab from the temp-blacklist. The user could use the same item in the context menu to flag a tab as something that should be blocked during the work phase. Even without the blocking of child tabs, this still might be a good idea.

I understand that the chrome devs have made it very hard to do much of anything with the tab bar, so the best you could do might be changing the favicon or title text, rather than the whole tab.

The more I think about this idea, the more I like it. If the half-dozen tabs I open up during my break were all bright red, or something, it would be a nice reminder that perhaps I should close some of them. That might be widening the scope of the app too much, though.

matchu commented 11 years ago

Hmm. I'm hesitant to touch title and favicon, because the current implementation doesn't replace the page, but rather attempts to cover it up. If a page still expects to have control over its own title and favicon and change it, the page could un-distinguish the tab pretty quickly, and, in very rare cases, it might break page logic if it tries to read the title/favicon and act on their contents. Not necessarily a dealbreaker, but worth considering.

bbendick commented 9 years ago

I would like to submit a pull request to suppress the count notifications that Facebook adds to its title bar, which I've found distracting to my "strictflow". If it was a user preference whether or not to allow that, would you allow altering the title?

matchu commented 9 years ago

Hmm. That sounds like it could get into feature creep fast: should we do the same for any other site with notifications? The manual solution of closing tabs with potentially distracting titles is simple enough that I don't think it needs to be automated right now. (I'm kinda interested in the idea of suppressing any title changes while a page is blocked, but I'm not sure that's feasible in the DOM API.)