Hi, I thought I'd open this issue before I add the feature (unless anyone else wants to take it?).
Since Shift+H
is the back command and Shift+L
is the forward command, and since in chrome you can hold Ctrl
and click back and it will open the previous page in a new tab (similarly for forward), I propose that Ctrl+Shift+H
should be back-and-open-new-tab and Ctrl+Shift+L
is forward-and-open-new-tab.
Do people agree with this? I'd like to have it included so am happy to add the feature, just want to check that it would be wanted before I start.
I do agree that would be nice. I've found myself using the mouse when I've wanted to do this.
This seems to be a dup of #731 (although that was closed due to lack of interest). Have you given any thought to implementation? As I mentioned on the old issue, ytH
(and ytL
) should do the same, but tying that up into 1 action would be nice.
Thanks @mrmr1993 I didn't see the old issue, good point on the ytH
(/ytL
).
I haven't actually looked at implementation yet, I wanted to double check it would be wanted as I wouldn't want to write a feature that doesn't get merged (seems a waste of time). I'll have a glance a little later and see what the implementation is likely to look like (I don't anticipate it being difficult to implement but you never know). Did you have any thoughts on that point?
I'm away from my computer for the weekend, so I can't write/test anything in its entirety, but if I were to write it, I'd expect an implementation to look something like
duplicateAndForward: (count) ->
chrome.tabs.getCurrent (tab) ->
chrome.tabs.duplicate(tab.tabId, (tab) ->
chrome.tabs.executeScript tab.tabId,
code: "history.go("+count+")"
matchAboutBlank: true
duplicateAndBack: (count) -> @duplicateAndForward(-count)
I don't especially approve of the use of executeScript
, especially as it essentially constitues an eval
, but I think it is probably the easiest and most concise way to achieve what we want. With this code, you'd also want to set passCountToFunction: true
in commands.coffee to make sure the initial count
argument is a number (instead of a callback function).
Beyond this, I believe history.go
is a no-op if the passed index is out of range. This means that, if we can't go next/prev by the required amount, the tab is just duplicated as is, which feels like bad UX. I haven't looked at the HTML5 history API extensions, but I think checking history.state
would give some insight into whether or not to act at all, and we could also then bound count
by the acceptible range.
Hope some of this helps!
Also, the code was supposed to read forwardInNewTab
and backInNewTab
, wasn't paying enough attention, sorry!
So should this deal with multiple backs or forwards? how would that work (from a u.i. perspective)?
My instinct was that it should be pretty much identical in terms of code, and somebody might find it useful, so why not.
I assumed that the UI for repetition would be to open a single new tab count
steps back/forward in history (or as many as possible up to that number), rather than opening a new tab for each step, or some other alternative. If there are no pages to go back/forward to, I would prefer that the command does nothing; anything else feels confusing to me.
cool. Until I read your thing I hadn't really thought to implement it like that, but I agree, that sounds like the most useful implementation. Cheers for your help, should make it far easier to implement. :smile:
I've submitted a PR (#1074) that tries to implement this. Since I haven't been able to find a way to query the history of an individual tab, the potentially bad UX of just duplicating the current tab is possible.
I'd like this feature to be implemented, and tbh I think it's more intuitive than ytH
even though I am glad I know this shortcut now. Just to make sure, on a Mac it would be CMD+SHIFT+H
right?
Maybe we should just publicize yt,shift+H
more. (in the readmes)