The bug happens when: - The signature of a xpi is invalid (e.g. by bug 1548973 without hotfix). - The last modified date of the xpi does not match with the one in our database. - Firefox restarts. About mismatch ing last modified date (`mtime`): - In my STR, I used `faketime` (on Linux) to run Firefox in the past without changing the clock of the system. This resulted in an observable difference in `mtime` values. - When I change the system-wide clock, the `mtime` does not change. (tested on Linux and macOS) - When the xpi (or even the whole profile directory) is modified or copied without preserving timestamps, the bug *will* be triggered. --- (In reply to Andrew Swan [:aswan] from comment #1) > The stack trace (plus additional information provided offline by Rob) implies that we are scanning for sideloads. I checked again, and from the stack trace it is obvious that we are not scanning for sideloads. The stack trace from comment #0 clearly points to [`startup`](https://searchfox.org/mozilla-release/rev/428b60a515be4ca901d5c64596d5b910c86db415/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2570) as the caller of `processFileChanges`, *not* `getNewSideloads`. Being called from `startup` is normal, especially with the schema bump. The reason for not seeing the measure you were asking for is not recorded by default on release builds. When I [enable extended recording on release](https://searchfox.org/mozilla-central/rev/06578bfadb5bdc5faee81f7e9b3c3fed21e616e0/toolkit/components/telemetry/app/TelemetryUtils.jsm#249), I do get `XPIDB_startup_load_reasons = [directoryState]`. When I dig a bit deeper, I see that the [xpis are considered changed because the mtime changed](https://searchfox.org/mozilla-central/rev/b4e790d05f5a146d186c238bac5601a553581d23/toolkit/mozapps/extensions/internal/XPIProvider.jsm#1386,1424). In my test case, I created the first version of the profile with `faketime`, and the mtime difference matches with what I had set. When I fix up the timestamps *before* starting Firefox again with the correct time, then the add-on package is preserved. --- (In reply to voltron from comment #6) > We already got several reports from users that Firefox has removed our extension completely. Do you know whether they tried to > Is there something I can do as a developer? For instance submit a new version with the ID in the manifest.json? When this bug happens, the add-on entry has been deleted from the user profile. Your updates won't reach the user in this case. > Or should I just do nothing and hope that I won't lose vast majority of my users? There is nothing that you can do to work around this bug. You can try to assess the impact by looking at the statistics dashboard of your add-on, at `https://addons.mozilla.org/developers/firefox/addon/<your addon sug here>/statistics`, and check if the number of daily users drops significantly compared to before. Make sure to look at the graph of multiple weeks, to account for expected deviations (e.g. fewer users in the weekends/holidays compared to weekdays).
Bug 1549129 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The bug happens when: - The signature of a xpi is invalid (e.g. by bug 1548973 without any fix (hotfix or bug 1549061)). - The last modified date of the xpi does not match with the one in our database. - Firefox restarts. About mismatch last modified date (`mtime`): - In my STR, I used `faketime` (on Linux) to run Firefox in the past without changing the clock of the system. This resulted in an observable difference in `mtime` values. - When I change the system-wide clock, the `mtime` does not change. (tested on Linux and macOS) - When the xpi (or even the whole profile directory) is modified or copied without preserving timestamps, the bug *will* be triggered. --- (In reply to Andrew Swan [:aswan] from comment #1) > The stack trace (plus additional information provided offline by Rob) implies that we are scanning for sideloads. I checked again, and from the stack trace it is obvious that we are not scanning for sideloads. The stack trace from comment #0 clearly points to [`startup`](https://searchfox.org/mozilla-release/rev/428b60a515be4ca901d5c64596d5b910c86db415/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2570) as the caller of `processFileChanges`, *not* `getNewSideloads`. Being called from `startup` is normal, especially with the schema bump. The reason for not seeing the measure you were asking for is not recorded by default on release builds. When I [enable extended recording on release](https://searchfox.org/mozilla-central/rev/06578bfadb5bdc5faee81f7e9b3c3fed21e616e0/toolkit/components/telemetry/app/TelemetryUtils.jsm#249), I do get `XPIDB_startup_load_reasons = [directoryState]`. When I dig a bit deeper, I see that the [xpis are considered changed because the mtime changed](https://searchfox.org/mozilla-central/rev/b4e790d05f5a146d186c238bac5601a553581d23/toolkit/mozapps/extensions/internal/XPIProvider.jsm#1386,1424). In my test case, I created the first version of the profile with `faketime`, and the mtime difference matches with what I had set. When I fix up the timestamps *before* starting Firefox again with the correct time, then the add-on package is preserved. --- (In reply to voltron from comment #6) > We already got several reports from users that Firefox has removed our extension completely. Do you know whether they tried to > Is there something I can do as a developer? For instance submit a new version with the ID in the manifest.json? When this bug happens, the add-on entry has been deleted from the user profile. Your updates won't reach the user in this case. > Or should I just do nothing and hope that I won't lose vast majority of my users? There is nothing that you can do to work around this bug. You can try to assess the impact by looking at the statistics dashboard of your add-on, at `https://addons.mozilla.org/developers/firefox/addon/<your addon sug here>/statistics`, and check if the number of daily users drops significantly compared to before. Make sure to look at the graph of multiple weeks, to account for expected deviations (e.g. fewer users in the weekends/holidays compared to weekdays).
The bug happens when: - The signature of a xpi is invalid (e.g. by bug 1548973 without any fix (hotfix or bug 1549061)). - The last modified date of the xpi does not match with the one in our database. - Firefox restarts. About mismatch last modified date (`mtime`): - In my STR, I used `faketime` (on Linux) to run Firefox in the past without changing the clock of the system. This resulted in an observable difference in `mtime` values. - When I change the system-wide clock, the `mtime` does not change. (tested on Linux and macOS) - When the xpi (or even the whole profile directory) is modified or copied without preserving timestamps, the bug *will* be triggered. --- (In reply to Andrew Swan [:aswan] from comment #1) > The stack trace (plus additional information provided offline by Rob) implies that we are scanning for sideloads. I checked again, and from the stack trace it is obvious that we are not scanning for sideloads. The stack trace from comment #0 clearly points to [`startup`](https://searchfox.org/mozilla-release/rev/428b60a515be4ca901d5c64596d5b910c86db415/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2570) as the caller of `processFileChanges`, *not* `getNewSideloads`. Being called from `startup` is normal, especially with the schema bump. The reason for not seeing the measure you were asking for is not recorded by default on release builds. When I [enable extended recording on release](https://searchfox.org/mozilla-central/rev/06578bfadb5bdc5faee81f7e9b3c3fed21e616e0/toolkit/components/telemetry/app/TelemetryUtils.jsm#249), I do get `XPIDB_startup_load_reasons = [directoryState]`. When I dig a bit deeper, I see that the [xpis are considered changed because the mtime changed](https://searchfox.org/mozilla-central/rev/b4e790d05f5a146d186c238bac5601a553581d23/toolkit/mozapps/extensions/internal/XPIProvider.jsm#1386,1424). In my test case, I created the first version of the profile with `faketime`, and the mtime difference matches with what I had set. When I fix up the timestamps *before* starting Firefox again with the correct time, then the add-on package is preserved. --- (In reply to voltron from comment #6) > We already got several reports from users that Firefox has removed our extension completely. Do you know whether they tried to copy or modify their Firefox profile? Maybe manually or by some other external software? > Is there something I can do as a developer? For instance submit a new version with the ID in the manifest.json? When this bug happens, the add-on entry has been deleted from the user profile. Your updates won't reach the user in this case. > Or should I just do nothing and hope that I won't lose vast majority of my users? There is nothing that you can do to work around this bug. You can try to assess the impact by looking at the statistics dashboard of your add-on, at `https://addons.mozilla.org/developers/firefox/addon/<your addon sug here>/statistics`, and check if the number of daily users drops significantly compared to before. Make sure to look at the graph of multiple weeks, to account for expected deviations (e.g. fewer users in the weekends/holidays compared to weekdays).