[Feature] Duplicate & back?

[JayBrown]

Most users have probably had the experience that they clicked on a link, but really wanted to control-click. So an undo method for this inadvertent action would be great addition, i.e. not just duplicate, but duplicate the tab, and direct the original tab back to the previous page, while bringing to foreground either the duplicate tab or the original (based on user preferences).

Possible?

PS: idea inspired by the Clone & Back and TabKeys Safari extensions by @canisbos

[Skeletonxf]

I believe it is possible, but not currently without obtaining and using permission to "access your data for all websites" as would be said when requesting the permission.

The permissions for manipulating tabs are split into not requesting anything, activeTab and tabs. With activeTab the extension can access data like the url of the tab it is invoked in, but not others. With tabs the extension can access all data for all tabs and produces the aforementioned warning. I intend to stay with activeTab only.

If would be convenient if there was a way to directly access the history of the tab the extension is invoked in. Unfortunately there does not seem to be any way to access the history of a tab via that tab. The proof of concept linked there instead requires listening to every tab the user creates in order to know where the back button of a particular tab will go.

I do not think this feature is currently possible without the tabs permission, and listening to every tab the user opens. Instead of requesting all data for all websites at installation time the tabs permission could be requested when the user first tries to duplicate & back but it would then be too late to work on that first use. Regardless, while I would grant such a permission to an ad blocker, I do not think it is reasonable to request this in a tab duplicator.

If it becomes possible to query this history from the active tab only then I will take another look. New features are being added to Web Extension APIs over time, and accessing the back button history of a tab seems like a common use case.

[JayBrown]

For those on macOS and interested in this functionality, here's a little AppleScript that does the job. I call it directly from the TouchBar using BetterTouchTool:

tell application "Firefox"
	activate
	tell application "System Events"
		keystroke "l" using command down
		keystroke "c" using command down
	end tell
	delay 0.5
	set theOriginalURL to (return the clipboard)
	tell application "System Events"
		key code 48
		key code 123 using command down
	end tell
	delay 0.5
	open location theOriginalURL
end tell

[groszdaniel]

If would be convenient if there was a way to directly access the history of the tab the extension is invoked in. Unfortunately there does not seem to be any way to access the history of a tab via that tab. The proof of concept linked there instead requires listening to every tab the user creates in order to know where the back button of a particular tab will go.

I do not think this feature is currently possible without the tabs permission, and listening to every tab the user opens. Instead of requesting all data for all websites at installation time the tabs permission could be requested when the user first tries to duplicate & back but it would then be too late to work on that first use. Regardless, while I would grant such a permission to an ad blocker, I do not think it is reasonable to request this in a tab duplicator.

If it becomes possible to query this history from the active tab only then I will take another look. New features are being added to Web Extension APIs over time, and accessing the back button history of a tab seems like a common use case.

Isn't it possible to inject JavaScript into the active tab to read/change its history via the History API?

(I've found your extension useful on Firefox for Android, where duplicating a page is not a built-in feature.)

[Skeletonxf]

It may be? JavaScript running in the original page might be able to use the window.history.back() API. I can take a look at if this method is feasible to implement. The UI may be a little tricky as it won't be possible to tell the user where the back navigation will be going and it won't work in privileged tabs

[groszdaniel]

I'd say the best thing would be to copy the (backward and forward) history of the original tab into the new tab, like the built-in Duplicate tab feature does on desktop, though I now realize that's different from the request this issue originally requested. (When I posted my last comment, I though this issue was essentially about Back not working in the duplicated tab, though I now realize that it instead requested actually going back in the original tab.)

[Skeletonxf]

Thanks for the suggestion groszdaniel. It seems possible, the happy path of navigating the user back works pretty well. It requires adding the scripting permission but I had needed that on Image Extract from the start and Firefox still lists the addon as having no permissions so I don't think that will be a concern.

I'll need to also dynamically hide/show the button when the user duplicates a tab that doesn't have anywhere to go back to before I can consider the implementation properly done and potentially releasable, but hopefully that will work by checking if the history length is greater than 1 or not and then working out how to communicate that to the advanced duplication page.

[Skeletonxf]

Slowly getting there but I think this is blocked again. The functionality actually does work as of fa5dd24 but it can't accurately detect when the option to navigate back can be available. I think I'm going to have to wait on the Navigation API to land https://bugzilla.mozilla.org/show_bug.cgi?id=1777171 so I can use canGoBack, as I don't want to release functionality where the button sometimes shows as available but does nothing.

[groszdaniel]

Yeah, it looks like I was wrong when I thought that injecting JavaScript and using the History API could be used to read the history entries of the old tab and duplicate them in the new tab: the History API supports going back and forward, but doesn't support querying the entire history at once. The only way the History API could be used to query whether we can go back is to actually go back in the old tab, then inject JS again to see if something happened, then go forward, but that would be slow, cumbersome, and it could have unwanted side-effects.

But unfortunately the Navigation API doesn't solve it either: for presumably privacy/security reasons, its list of entries only shows pages from the same origin. Its canGoBack property is also only true if you can go back within the same origin, if you came from a different origin (via a link or by entering something in the address bar) it will be false.

EDIT: I don't get why history has a length property but not one that shows the current position in it.

[Skeletonxf]

That could be disappointing, from the docs I thought canGoBack will fit the check I need, as I just want to know if it's possible to go backwards in the tab's current page (and not any iframes) which shouldn't have any privacy concerns.

The canGoBack read-only property of the Navigation interface returns true if it is possible to navigate backwards in the navigation history (i.e. the currentEntry is not the first one in the history entry list), and false if it is not.

If occasionally the user can go back to a different origin but the addon can't detect that as possible and removes the button I think the functionality would still have some value. I imagine most of the time a user is going to be navigating within the same origin when they want a second tab open 1 step apart

[groszdaniel]

But also, isn't isn't it now possible to request permissions at runtime? You could then make a single extension that can get extra functionality depending on whether the user grants access data on all tabs permission.

[Skeletonxf]

I think that goes back to the issue I mentioned in 2018 earlier in this thread unfortunately.

The proof of concept linked there instead requires listening to every tab the user creates in order to know where the back button of a particular tab will go.

Runtime permissions make the permission a little less concerning, but still have the issues of I'll have another setting that needs manual testing thereafter, listening to every tab created by the user for an edge case of only 1 option the addons provides is really overkill and may use excess power/resources., and it won't work on the first journey when the user wanted to grant the permission.

[groszdaniel]

I think that goes back to the issue I mentioned in 2018 earlier in this thread unfortunately.

The proof of concept linked there instead requires listening to every tab the user creates in order to know where the back button of a particular tab will go.

Runtime permissions make the permission a little less concerning, but still have the issues of I'll have another setting that needs manual testing thereafter, listening to every tab created by the user for an edge case of only 1 option the addons provides is really overkill and may use excess power/resources., and it won't work on the first journey when the user wanted to grant the permission.

Ah, indeed, there still doesn't seem to be an API for that. See w3c/webextensions#203.