Deprecate `GM.getTab` and `GM.saveTab` APIs

[ACTCD]

This set of APIs is very unintuitive for both developers and users.

First is the name, which is actually more like getTabBindData and saveTabBindData than what it appears now.

Secondly, I understand that its function is actually to track tabs across origins, which means that it actually only needs an identifier like tabID, and any logic can be completed using the existing GM.*Value APIs.

And GM.*Value is isolated based on user scripts, but the current tabObj implementation is actually shared between user scripts, which means it can create conflicts and surprises.

I think we should do away the APIs in its current form, and just provide a privileged extensions API bridge similar to the getTabID or getTab(infos), with a clear warning to the user that this can be used to track tabs across origins.

We should also reference APIs such as sessions.setTabValue() and sessions.getTabValue() based on usage scenarios. (Currently not available in Safari)

Originally posted by @ACTCD in #296 (comment)

[maggch97]

My concern is this API is provided by tampermonkey, and most scripts are designed for that. Data from different script is not isolated, it's may be a problem and cause some conflict. But this behavior is same with the latest tampermonkey.

Yes, getTabID is good, it gives script developers another option and provides a way to avoid conflict. But it needs all developers change their code only for iOS userscripts and distribute 2 scripts, one is for tampermonkey and one is for iOS userscripts.

Using GM.*Value to store the tab state, one problem I thought of is that developers need to clean the tab data carefully.

I think the better way is to keep the getTab and saveTab and also add other API like getTabID

[ACTCD]

@maggch97 This is actually the reason why I hope to deprecate them, they are only supported by one extension and lack good design and documentation. And according to one statistic, their usage in the userscript market is very low.

Our vision is to reduce confusion and always encourage best security practices, both for developers and users.

Compatibility has never been our primary goal. Providing sustainably maintained and robust code and logic, as well as clear and simple APIs is ultimately more beneficial to the development of user scripts field.

In fact I think cases where tabs need to be tracked across origins should exist as extensions rather than user scripts.

Providing an extension API bridge is just an idea, at least it is a more transparent way to implement it. This should require more careful consideration and design, like the set of APIs in Firefox I mentioned.

So, I guess deprecating them would be the first step. We will add deprecation hints in v5.0 and remove them in v6.0.

[ACTCD]

@maggch97

Using GM.*Value to store the tab state, one problem I thought of is that developers need to clean the tab data carefully.

I think this is a separate issue, it's not just for tab data, it's the same issue for any data life cycle.

A better way to address it would be to redesign the userscript's data storage so that they have a different lifecycle similar to the storage of the page/extension itself.

But I'm not sure if the complexity this brings is worth it for user scripts. Maybe providing the end user with an interface to view and clean up the user script storage space is also an effective solution (#370).