为什么要删除 GM_openInTab 的 useOpen 选项

[DreamNya]

上图分别是
offscreen 的 window.open
service worker 的 chrome.windows.create
service worker 的 chrome.tabs.create

看出区别了吗？

useOpen的意义从来不是打开原本打不开的页面（协议链接在MV2时期就可以通过chrome.tabs.create打开），而是可以弹出一个选项框，使浏览器记住以后打开该协议链接时无需再强制确认，可以直接静默打开
这对一些自动化项目、前后端互通的项目来说非常重要

另外useOpen选项属于向上兼容，并不影响油猴、暴力猴的API，且不影响任何不需要这个API的用户

[CodFrm]

我之前以为是同样的效果，没有意义就进行了删除，我会在下个小版本加回去

[cyfung1031]

@DreamNya https http 以外的特殊连结都默认以前的"useOpen"可接受吗？
不用另外搞一堆设定吧

[DreamNya]

对我个人无所谓
但是对于脚本猫，对于其他脚本开发者，我觉得明确一下具体有什么区别比较好

[cyfung1031]

就默认吧
不想一堆选项
搞得跟 TM VM 不一样奇奇怪怪的

[DreamNya]

不一样没什么不好，有差异化，才不会同质化
不然什么都一样，我为什么还要来用脚本猫，直接去用油猴、暴力猴不就好了

[CodFrm]

默认也可以接受，对于非 http/https （也许还有ftp之类？），行为上 window.open 更友好

不过之前已经是使用了 useOpen 这个选项，两种方式上的行为也不一样，避免有什么未知的问题，我觉得还是增加一下 useOpen 会更好点 （测试了一下TM/VM都是 chrome.tabs.create 的方式）

[cyfung1031]

不一样没什么不好，有差异化，才不会同质化
不然什么都一样，我为什么还要来用脚本猫，直接去用油猴、暴力猴不就好了

默认也可以接受，对于非 http/https （也许还有ftp之类？），行为上 window.open 更友好

不过之前已经是使用了 useOpen 这个选项，两种方式上的行为也不一样，避免有什么未知的问题，我觉得还是增加一下 useOpen 会更好点 （测试了一下TM/VM都是 chrome.tabs.create 的方式）

GM.openInTab 是为了执行 chrome.tabs.create
里面有其他的客制化参数可选
由一开始加 useOpen 就是错
先不讲英文词不达意

GM的API是用来兼容其他UserScript Managers
不是搞一堆自家的玩意
ScriptCat有 CAT_XXXXX

用了这个 useOpen, 其他的参数就会对不上
因为它不是用 chrome.tabs.create

然后这个词不达意，又会让人家以为这个是用来开新视窗用
然后又因为这个，人家会骂为什么加了 useOpen 就不能 active: false

这个 useOpen 既然目的是用来打开特殊连结，ScriptCat就默认用这个方式打开特殊连结
不然就做一个CAT_XXXXXX 打开这种特殊连结

TM 和 VM 都不是考虑打开特殊连结
打开特殊连结就不会成为一个Tab
一开始用 GM.openInTab(...) 当 window.open 来处理就是不适当
应该做一个新的API处理