Edit: am on Firefox 66, Linux (Debian Buster/testing), using Firefox from Mozilla directly (not through repositories), and my internet/wifi should not have disconnected. System has been up since 2019-05-03T17:30:00Z, suspended before that.
Edit: am on Firefox 66, Linux (Debian Buster/testing), using Firefox from Mozilla directly (not through repositories), and my internet/wifi should not have disconnected. System has been up since 2019-05-03T17:30:00Z, suspended before that.
Just a thought, might it be that you suspend (sleep mode in Windows) your system? So not restart the browser, technically, but iirc applications still receive some event when this happens. At the very least, open connections would break. Any TLS connection would re-validate the certificate. In that case, going offline would also trigger it. Have you done any of those (suspend, be offline / switch networks)?
EDIT: Android disabled Add-Ons when I switched from WiFi to mobile connection.
Indeed, I see in about:studies,
hotfix-reset-xpi-verification-timestamp-1548973•Complete This study sets app.update.lastUpdateTime.xpi-signature-verification to 1556945257
(unfortunately I can not see when it was run in about:studies)
i.e. this "study" has reset the timestamp of the last signature verification to this morning (when I have started Firefox). Since I read around that Firefox performs the check only every 24 hours, I guess that this is reason why we have not been experiencing the problem. We have now another day, after which we will have to reset the timestamp again (if it has not been solved upstream). The field is available/accessible also in about:config.
P.S. To be fairly honest, I was a bit surprised about the "studies" feature, I can not recall when it was introduced, but it is probably my fault for having overlooked it.
https://twitter.com/mozamo/status/1124569680662777856
> We deployed a fix to users who hadn't had their add-ons disabled to make sure they saved that way. You're in that group. :)