(In reply to Dennis Schubert [:denschub] from comment #4) > ... > I agree that having this in a pre-Release channel for a while before relasing is a good idea, as that would also allow us to intervene if needed. However, I would prefer this to be in `EARLY_BETA_OR_EARLIER` instead of just Nightly, as our Beta population is significantly larger. I'd rather have this spend some stabilization cycles in Beta where this gets more exposure. I'll leave it up to you if you want to have this Nightly-only first for a while before exposing to Beta, I'm fine either way. Yours is a very good point, and so I'm updating the attached patch to disable the InstallTrigger global on nightly and early beta (and I'll also updating this bugzilla issue subject message to reflect that), thanks a lot for bringing it up! > If we do discover breakage, we can easily ship a WebCompat intervention that sets `window.InstallTrigger` to something not-`undefined`. I just tested a patch to make sure this works, and it does as expected. So even if regressions pop up, we should be able to handle them in an intervention, without having to toggle the pref again. > > I'll double-check with the team if I missed anything critical before r+'ing your patch, but this all looks like it's hopefully not a big deal. That sounds great to me too, thanks a lot also for looking so quickly into this! As an additional side note, once the [last try push](https://treeherder.mozilla.org/#/jobs?repo=try&revision=ed19e50917ee64ae743dca43cd51e23164a0adc3) confirms that we didn't introduce any new tests that would fail with InstallTrigger disabled (we adapted quite an amount of tests across the tree as part of Bug 1754441 in preparation for these additional tests) both Bug 1772901 path and this one will be pushed to autoland and will both get in Nightly 103, and so: - During Nightly 103 and Early Beta 103 => InstallTrigger global is going to be completely hidden (per pref flipped by the patch attached to this issue). - During Late Beta 103, DevEdition 103 and Release 103 => InstallTrigger methods will be all hidden, the InstallTrigger global to be still enumerable and set to `null` (per pref flipped by the patch attached to Bug 1772901). As a potential "worst case scenario": - If a subset of the websites using InstallTrigger global for UserAgent detection are doing a different kind of check that isn't still `true` with `InstallTrigger` set to `null` (most of them should be using the common `typeof InstallTrigger !== "undefined"` and should still work just fine once Bug 1772901 gets to release), we may need to a Webcompat intervention, but it would basically the same one mentioned in comment 4 and so it seems that we will be prepared also to the less likely "worst case scenario" (In addition to that we could also flip these two prefs back to `true` through AddonManager's RemoteSettings, that was also part of the preparation work from Bug 1754441 as an additional "very last resort", because unlike the WebCompat intervention through AMRemoteSettings we can only disable/enable InstallTrigger deprecation prefs globally and not on a per-origin basis).
Bug 1772905 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Dennis Schubert [:denschub] from comment #4) > ... > I agree that having this in a pre-Release channel for a while before relasing is a good idea, as that would also allow us to intervene if needed. However, I would prefer this to be in `EARLY_BETA_OR_EARLIER` instead of just Nightly, as our Beta population is significantly larger. I'd rather have this spend some stabilization cycles in Beta where this gets more exposure. I'll leave it up to you if you want to have this Nightly-only first for a while before exposing to Beta, I'm fine either way. Yours is a very good point, and so I'm updating the attached patch to disable the InstallTrigger global on nightly and early beta (and I'll also updating this bugzilla issue subject message to reflect that), thanks a lot for bringing it up! > If we do discover breakage, we can easily ship a WebCompat intervention that sets `window.InstallTrigger` to something not-`undefined`. I just tested a patch to make sure this works, and it does as expected. So even if regressions pop up, we should be able to handle them in an intervention, without having to toggle the pref again. > > I'll double-check with the team if I missed anything critical before r+'ing your patch, but this all looks like it's hopefully not a big deal. That sounds great to me too, thanks a lot also for looking so quickly into this! As an additional side note, once the [last try push](https://treeherder.mozilla.org/#/jobs?repo=try&revision=f893a92df747f7454aeddd3380c12563f45ddd6b) confirms that we didn't introduce any new tests that would fail with InstallTrigger disabled (we adapted quite an amount of tests across the tree as part of Bug 1754441 in preparation for these additional tests) both Bug 1772901 path and this one will be pushed to autoland and will both get in Nightly 103, and so: - During Nightly 103 and Early Beta 103 => InstallTrigger global is going to be completely hidden (per pref flipped by the patch attached to this issue). - During Late Beta 103, DevEdition 103 and Release 103 => InstallTrigger methods will be all hidden, the InstallTrigger global to be still enumerable and set to `null` (per pref flipped by the patch attached to Bug 1772901). As a potential "worst case scenario": - If a subset of the websites using InstallTrigger global for UserAgent detection are doing a different kind of check that isn't still `true` with `InstallTrigger` set to `null` (most of them should be using the common `typeof InstallTrigger !== "undefined"` and should still work just fine once Bug 1772901 gets to release), we may need to a Webcompat intervention, but it would basically the same one mentioned in comment 4 and so it seems that we will be prepared also to the less likely "worst case scenario" (In addition to that we could also flip these two prefs back to `true` through AddonManager's RemoteSettings, that was also part of the preparation work from Bug 1754441 as an additional "very last resort", because unlike the WebCompat intervention through AMRemoteSettings we can only disable/enable InstallTrigger deprecation prefs globally and not on a per-origin basis).