火狐39，cookies常丢失【找到罪魁了！！】

火狐35一直正常，自打8日升级到39.03，cookies已丢失三次
早起还正常，关机休眠，午间开机启动火狐39，发现cookies丢失，访问常去网站都要重新登陆，
配置文件目录下，原1.5M的cookies.sqlite，变成了500多K，原1.5M文件变成了cookies.sqlite.bak，同时还出现个cookies.sqlite-rebuild，跟现有的cookies.sqlite大小字节一样
去掉cookies.sqlite.bak后面的.bak，删除另两个文件，启动火狐cookies恢复正常，之前就这样处理过，但不定何时又再次出现上面这种情况

从35升级到39，更新了70多已签名扩展，包括启用和禁用的，第一次是全部已启用扩展一次更新完成，再重启的火狐，当时cookies就丢失过，后来恢复备份，几个几个一组更新已启用扩展，关闭重开火狐有十多次，cookies没再丢失，但最近几天又丢了两次，没有规律，这到底是怎么回事？

其他文件没发现异常。

描述：39cookies异常

图片：火狐39cookies异常JT-287.png

20150826
找到原因了，是ushare造成，只要用ushare登陆，cookies就丢失，即出现上面我描述的现象——cookies.sqlite被更名加上.bak，又生成个524288字节的cookies.sqlite

在火狐35都正常，可能是ushare1.4.6不兼容火狐39造成的cookies丢失
这个扩展已经三年没更新，被作者抛弃了看来是，分享页面很好用，还能截图分享，没找到同样功能的类似扩展

yfdyh000：有可能Cookies数据库中的那个weibo的部分损坏了，写入就会坏掉。

可以找个SQLite程序+命令转储一下（但很麻烦，我弄了很久才会），或者Cookies管理器的扩展导入导出一下，在重建/新的数据库中导入原数据。或者干脆重建一下看看...回到原帖

用自动重建的cookies，ushare退出登陆了几次，没出现cookies再次重建的情况，继续观察

yfdyh000：有可能Cookies数据库中的那个weibo的部分损坏了，写入就会坏掉。

可以找个SQLite程序+命令转储一下（但很麻烦，我弄了很久才会），或者Cookies管理器的扩展导入导出一下，在重建/新的数据库中导入原数据。或者干脆重建一下看看...回到原帖

不再恢复之前的cookies了，就用它自动重建的文件，看看以后是否还有丢失情况

yfdyh000：其实，也可能根本跟扩展无关，就是个偶发性的浏览器bug。
我在38beta时，完全无规律，启动时就随机性损坏并重建。
可以转40甚至Nightly用用看吧，如果没发生，证明旧版本留存了偶发bug没发现。回到原帖

更新到40.0.2了依然遇到这情况，而且似乎更频繁了的样子，38只遇到过一次，到39了就多了起来。
不过一般是隔好几天才会遇到，写了个批处理，点一下就搞定了，所以也没怎么在意。

tulip17：看来丢失cookies有多种原因，我这还是有规律的，那个配置下只要一登陆ushare就丢cookies回到原帖

有可能Cookies数据库中的那个weibo的部分损坏了，写入就会坏掉。

可以找个SQLite程序+命令转储一下（但很麻烦，我弄了很久才会），或者Cookies管理器的扩展导入导出一下，在重建/新的数据库中导入原数据。或者干脆重建一下看看。不过我38beta时，重建过一两次，好像没什么用。

我目前的主配置是Firefox 3.6左右用下来的，也没什么问题。

yfdyh000：其实，也可能根本跟扩展无关，就是个偶发性的浏览器bug。
我在38beta时，完全无规律，启动时就随机性损坏并重建。
可以转40甚至Nightly用用看吧，如果没发生，证明旧版本留存了偶发bug没发现。回到原帖

看来丢失cookies有多种原因，我这还是有规律的，那个配置下只要一登陆ushare就丢cookies

yfdyh000：没装过这个应用。AMO用户挺少，才65。微博授权，共有 1383 人使用。
尝试装了并登录了，还试着重启了几次，没有发现丢失的情况，41beta和39.0.3都尝试了。

或许有其他原因。为什么不用40呢，也还没有强制签名的问题。回到原帖

我这个配置好像是从FF4一路升级上来，cookies老旧了？

tulip17：用39新建了配置，只装ushare，反复登陆退出，确实没出现cookies丢失问题，后来又装了multifox，仍然正常，看来我这个ushare弄丢cookies的现象还与其他条件有关，装了几十个扩展，没法一一排查了回到原帖

其实，也可能根本跟扩展无关，就是个偶发性的浏览器bug。
我在38beta时，完全无规律，启动时就随机性损坏并重建。
可以转40甚至Nightly用用看吧，如果没发生，证明旧版本留存了偶发bug没发现。

yfdyh000：没装过这个应用。AMO用户挺少，才65。微博授权，共有 1383 人使用。
尝试装了并登录了，还试着重启了几次，没有发现丢失的情况，41beta和39.0.3都尝试了。

或许有其他原因。为什么不用40呢，也还没有强制签名的问题。回到原帖

用39新建了配置，只装ushare，反复登陆退出，确实没出现cookies丢失问题，后来又装了multifox，仍然正常，看来我这个ushare弄丢cookies的现象还与其他条件有关，装了几十个扩展，没法一一排查了

但是我没装过ushare……

yfdyh000：在ESR结束支持前，官方应该不会把AMO上的这类扩展去掉吧……回到原帖

是哦！还有18个月多，不过还是及早备份比较好，估计这类xul扩展今后不会继续维护更新了，已经要死掉，换我也不会维护更新了。在18个月以后，AMO很可能会删掉这些xul扩展。

fang5566：这类扩展虽然不更新，但也没大问题，不过今后这些扩展大部分都要死掉啦，赶紧备份xpi吧，你还可以使用 palemoon回到原帖

在ESR结束支持前，官方应该不会把AMO上的这类扩展去掉吧……

tulip17：找到原因了，是ushare造成，只要用ushare登陆，cookies就丢失，即出现楼顶我描述的现象——cookies.sqlite被更名加上.bak，又生成个524288字节的cookies.sqlite

在火狐35都正常，可能是u...回到原帖

这类扩展虽然不更新，但也没大问题，不过今后这些扩展大部分都要死掉啦，赶紧备份xpi吧，你还可以使用 palemoon

tulip17：找到原因了，是ushare造成，只要用ushare登陆，cookies就丢失，即出现楼顶我描述的现象——cookies.sqlite被更名加上.bak，又生成个524288字节的cookies.sqlite

在火狐35都正常，可能是u...回到原帖

没装过这个应用。AMO用户挺少，才65。微博授权，共有 1383 人使用。
尝试装了并登录了，还试着重启了几次，没有发现丢失的情况，41beta和39.0.3都尝试了。

或许有其他原因。为什么不用40呢，也还没有强制签名的问题。