1318141 - Uninstall the outofdate-notifications system add-on

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Robert Strong (they/them - no direct email)]

Not sure which product and component this bug should be filed in or who actually takes care of this.

This add-on was added in bug 1280378 and it should be removed. Thanks!

Comment 1

[Robert Strong (they/them - no direct email)]

Ben, can you help out with this or direct this bug to someone that can?

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Do you mean unpublish it from Balrog so that no more users receive it, or actually uninstall it from the users who did receive it?

Comment 3

[Robert Strong (they/them - no direct email)]

Uninstall it

Comment 4

[Stephen A Pohl [:spohl]]

(In reply to :Felipe Gomes (needinfo me!) from comment #2)
> Do you mean unpublish it from Balrog so that no more users receive it, or
> actually uninstall it from the users who did receive it?

Isn't this synonymous? I thought unpublishing a system addon results in uninstalls.

Comment 5

[:Felipe Gomes (needinfo for replies!)]

I think it depends on how it's unpublished.. IIRC it's the difference between an empty response, and one with <addons></addons>. So that's why I wanted to clarify.

It's documented somewhere here:
http://gecko.readthedocs.io/en/latest/toolkit/mozapps/extensions/addon-manager/SystemAddons.html

Comment 6

[[e-mail] (:bhearsum)]

I've got to defer to rhelmer on exactly what we should serve for this - things have changed over the last few versions. It looks like we're only serving this to Firefox 44, and also publishing Loop 3.1.0 - so we'll want to continue serving that at the same time.

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to Ben Hearsum (:bhearsum) from comment #6)
> I've got to defer to rhelmer on exactly what we should serve for this -
> things have changed over the last few versions. It looks like we're only
> serving this to Firefox 44, and also publishing Loop 3.1.0 - so we'll want
> to continue serving that at the same time.

Just to make sure I understand, can you show me an example of the XML being served to these clients now?

The short answer is that removing it from the set should cause it to be uninstalled, so if you have now:

<updates>
 <addons>
  <addon id="loop" .../>
  <addon id="out-of-date" .../>
 </addons>
</updates>

Then just removing the "out-of-date" addon entry will cause this add-on to be removed on the next restart. You don't want to serve an empty set (<updates><addons/></updates>) to 44 as that'd disable built-in system add-ons.

This "empty set" behavior was modified in bug 1295732 for 49, so serving an empty set only removes updates and does not disable the built-in system add-ons.

Comment 8

[[e-mail] (:bhearsum)]

(In reply to Robert Helmer [:rhelmer] from comment #7)
> (In reply to Ben Hearsum (:bhearsum) from comment #6)
> > I've got to defer to rhelmer on exactly what we should serve for this -
> > things have changed over the last few versions. It looks like we're only
> > serving this to Firefox 44, and also publishing Loop 3.1.0 - so we'll want
> > to continue serving that at the same time.
> 
> Just to make sure I understand, can you show me an example of the XML being
> served to these clients now?
> 
> The short answer is that removing it from the set should cause it to be
> uninstalled, so if you have now:
> 
> <updates>
>  <addons>
>   <addon id="loop" .../>
>   <addon id="out-of-date" .../>
>  </addons>
> </updates>
> 
> Then just removing the "out-of-date" addon entry will cause this add-on to
> be removed on the next restart. You don't want to serve an empty set
> (<updates><addons/></updates>) to 44 as that'd disable built-in system
> add-ons.
> 
> This "empty set" behavior was modified in bug 1295732 for 49, so serving an
> empty set only removes updates and does not disable the built-in system
> add-ons.

From https://aus5.mozilla.org/update/3/SystemAddons/44.0/20160310153207/Darwin_x86_64-gcc3-u-i386-x86_64/en-GB/release/Darwin%2014.5.0/default/default/update.xml, should be:
<updates>
<addons>
<addon id="[e-mail]" URL="https://ftp.mozilla.org/pub/system-addons/hello/[e-mail]" hashFunction="sha512" hashValue="7e53369381eb0730b0a9e900c75195ec60b19e5ff3a40650814945793229ea49921125866212abbb98453d2f8193be3d2d3c13a74e6cd637718cde24982eda32" size="6102" version="3.1.0"/>
<addon id="[e-mail]" URL="https://ftp.mozilla.org/pub/system-addons/outofdate-notifications/[e-mail]" hashFunction="sha512" hashValue="b0d73e2d281dccd07bdcbae550f818843b40de409a07a35ed40b18d15ac1b9b4de4ea82ef3c4f4349ee41291822f3a0ae8a8304f7e16e7974b87102c918d57db" size="54958" version="1.3"/>
</addons>
</updates>

So, sounds like we should create a new Release based on SystemAddons-ff44-outofdate-1.3-loop-3.1.0, remove outofdate from it, and publish that to 44.0. Probably ckprice, osmose, or rdalal should take care of this, since they do most of the System Addon update changes.

Comment 9

[Robert Strong (they/them - no direct email)]

Michael, could you take this bug or know someone that can?

Comment 10

[Osmose [:osmose, :mkelly]]

Sure!

Test change: Updated rule 318 to only ship out loop 3.1.0. Tested with Firefox 44.0, and the outofdate add-on was uninstalled after triggering an update and restarting the browser.

Release change: Updated rule 324 to ship out only loop 3.1.0. The API endpoint isn't showing the outofdate add-on anymore:

https://aus5.mozilla.org/update/3/SystemAddons/44.0/20160310153207/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2014.5.0/default/default/update.xml

We should start seeing install counts of the outofdate add-on go down.