Greasemonkey 未能执行 GM_setValue()
我有一个 Greasemonkey 脚本,它使用 Javascript 对象来维护一些存储的对象。它涵盖了大量信息,但比遇到我的问题之前成功存储和检索的信息要少得多。一种价值观拒绝拯救,我一生都无法确定原因。以下问题代码:
- 适用于正在维护的其他较大对象。
- 目前处理的数据总量比以前要少。
- 不与任何函数或其他对象定义发生冲突。
- 可以(可选)在代码启动期间成功将问题存储键保存为“{}”。
this.save = function(table) {
var tables = this.tables;
if(table)
tables = [table];
for(i in tables) {
logger.log(this[tables[i]]);
logger.log(JSON.stringify(this[tables[i]]));
GM_setValue(tables[i] + "_" + this.user, JSON.stringify(this[tables[i]]));
logger.log(tables[i] + "_" + this.user + " updated");
logger.log(GM_getValue(tables[i] + "_" + this.user));
}
}
该问题始终可以重现,并且日志记录在 Firebug 中产生以下输出:
- Object { 54,10 = Object } // Expansion 显示了预期的完整内容,但有一个奇怪之处 - Firebug 以紫色突出显示对象键,而不是通常黑色用于匿名对象。
- {"54,10":{"x":54,"y":10,"name":"Lucky Pheasant"}} // 正确的字符串化 JSON。
- bookmarks_HonoredMule 已更新
- 未定义
我尝试更改对象键的格式,但没有效果。进一步缩小问题范围是,这个特定值在代码初始化期间成功保存为空对象(“{}”),但跳过它也没有帮助。重新加载页面确认非空对象的保存确实失败。
知道什么可能导致这种行为吗?我已经彻底探索了达到大小限制的可能性,但这似乎并不是问题所在——如前所述,我已经减少了存储使用量。其他较大的对象仍在保存,并且对象总数(本来就不高)已进一步减少,其数量大于我尝试在此处存储的数据量。
I have a Greasemonkey script that uses a Javascript object to maintain some stored objects. It covers quite a large volume of information, but substantially less than it successfully stored and retrieved prior to encountering my problem. One value refuses to save, and I can not for the life of me determine why. The following problem code:
- Works for other larger objects being maintained.
- Is presently handling a smaller total amount of data than previously worked.
- Is not colliding with any function or other object definitions.
- Can (optionally) successfully save the problem storage key as "{}" during code startup.
this.save = function(table) {
var tables = this.tables;
if(table)
tables = [table];
for(i in tables) {
logger.log(this[tables[i]]);
logger.log(JSON.stringify(this[tables[i]]));
GM_setValue(tables[i] + "_" + this.user, JSON.stringify(this[tables[i]]));
logger.log(tables[i] + "_" + this.user + " updated");
logger.log(GM_getValue(tables[i] + "_" + this.user));
}
}
The problem is consistently reproducible and the logging statments produce the following output in Firebug:
- Object { 54,10 = Object } // Expansion shows complete contents as expected, but there is one oddity--Firebug highlights the object keys in purple instead of the usual black for anonymous objects.
- {"54,10":{"x":54,"y":10,"name":"Lucky Pheasant"}} // The correctly stringified JSON.
- bookmarks_HonoredMule updated
- undefined
I have tried altering the format of the object keys, to no effect. Further narrowing down the issue is that this particular value is successfully saved as an empty object ("{}") during code initialization, but skipping that also does not help. Reloading the page confirms that saving of the nonempty object truly failed.
Any idea what could cause this behavior? I've thoroughly explored the possibility of hitting size constraints, but it doesn't appear that can be the problem--as previously mentioned, I've already reduced storage usage. Other larger objects save still, and the total number of objects, which was not high already, has further been reduced by an amount greater than the quantity of data I'm attempting to store here.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
事实证明,问题在于从 unsafeWindow 上下文调用 this.save() 。这是一种安全违规,但应该导致抛出访问违规异常:
相反,GM_setValue 没有执行任何操作就返回,并且后续日志记录指令也会执行,因此没有任何问题提示并且文档可能已过时。
为了以任何方式解决这个问题,我抽象了 GM_ 存储函数,以便我可以使用其他存储机制,因此解决方法是将所有保存指令放入在 setInterval 中运行的预先存在的清理例程中,类似于修复上述文档中描述的问题。 (使用现有间隔是为了防止过度创建计时器,这些计时器在过去会降低浏览器正常运行时间的性能。)
It turns out the issue was that of this.save() being called from an unsafeWindow context. This is a security violation, but one that should have resulted in an access violation exception being thrown:
Instead GM_setValue returns having done nothing, and the subsequent logging instructions also execute, so there was no hint of the issue and the documentation may be out of date.
In my quest to solve this problem by any means, I abstracted away GM_ storage functions so I could use other storage mechanisms, so the workaround will be to put all save instructions in a pre-existing cleanup routine that runs in setInterval, similar to the fix described in the aforementioned documentation. (The use of an existing interval is to prevent excessive creation of timers which have in the past degraded performance over browser uptime.)