1291705 - [Out Of Date Notification] Running 44.* with updated Profile(48) influences the Out Of Date notification system addon install

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[roxleitan]

[Description]
Although we recognize this is an edge case scenario unlikely to happen, we are concerned about the fact that we do not know the reason for which the profile is 44 is not triggering the Out Of Date system addon install: the reason might be that the snippet that we are using to trigger the add-on download contains functions that are deprecated in 48.
So given the fact that in a real life situation the system add-on will be triggered automatically our point of interest with this bug would be to know what exactly is influencing the profile and how that might create a scenario which we are likely to encounter in a real life user profile.

[Affected versions]:
44.*

[Affected platforms]:
Windows

[Prerequisites]:

1. Install FF latest version
2. Have unzipped FF target version
3. Outofdate notifications system add-on required configurations:
3.1 about:config set extensions.systemAddon.update.url to value 	"https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/release-sysaddon/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml"
3.2 about:config set extensions.logging.enabled	to value "True"
3.3 about:config Add string app.update.url.override with value "www.softvision.ro" 
4. Set update preferences ->  about:preferences#advanced and set Firefox updates to "Automatically install updates (recommended: improved security)"
5. Force system addons check : Open Tool/WebDeveloper/Web Console and run the snippet:   " Components.utils.import("resource://gre/modules/AddonManager.jsm"); AddonManagerPrivate.backgroundUpdateCheck(); "

In the Tools/ WebDeveloper/BrowserConsole a similar line should be listed: "addons.productaddons INFO Downloading from https://ftp.mozilla.org/pub/system-addons/outofdate-notifications/[e-mail] to /tmp/tmpaddon"

6. Restart FF to install the OutOfDate System Addon - !!!! Do not open About:Support to check if updates are being downloaded --> use about:support

[Steps to reproduce]:
1.Open unzipped FF target version with a new profile
2.Run Outofdate notifications system add-on required configurations on FF target version
3.Close FF target version 
3.Open installed FF latest version with profile created at step 1
4.Close FF latest version
5.Reopen FF target version with profile created at step 1

[Actual result]:
2.Outofdate notifications bar is displayed 
5.Outofdate notifications bar is not displayed

Comment 1

[Stephen A Pohl [:spohl]]

System addons that are incompatible with a particular version will be uninstalled, so when you use the Firefox 44 profile in Firefox 48, the system addon for Firefox 44 will be uninstalled. After going from the current version back to 44, did you rerun the snippet or wait for the system addon check to occur? If not, this is expected behavior until the next system addon check occurs and Firefox 44 has been restarted.

Comment 2

[Adrian Florinescu [:aflorinescu]]

The snippet for system addon check doesn't work anymore with the modified profile and we haven't noticed the automatic check occur so far (we still have no clue how often the automatic check occurs), we'll leave a 44 FF on to see if and when that automatic check happens. Maybe this should be a point of concern  itself and maybe you could help us by digging a bit to find out how often the automatic check for system add-ons is supposed to be performed. (might also be a problem that we are running custom prefs?)

Related to this particular issue, like Roxana pointed, this is an edge case scenario that is unlikely to happen in real life. However we will most definitely have various profiles that go the other way (old profiles that gathered lots of customisation) so we are thinking of seeing how the system add-on check and the system add-on install behaves and maybe extrapolate this scenario on profiles that come from earlier versions.

Comment 3

[Stephen A Pohl [:spohl]]

As discussed via IRC, setting n-i on you, Adrian. Please attach a complete console log and n-i rhelmer on it.

One thing that I forgot to mention: Please run the snippet in the browser console, not the web console. When you open the web console, click on the gear icon to get to settings, then enable the following two options:
"Enable browser chrome and add-on debugging toolboxes"
"Enable remote debugging"

Once you've done that, open Tools > Web Developer > Browser Console and paste the snippet there. We should run the snippet in the browser console for all our tests. If that's not clear, we should update the test cases to say so. Thanks!

Comment 4

[Adrian Florinescu [:aflorinescu]]

We can't reproduce the error we got yesterday when we were running the snippet on a profile that came from a higher than 44.
Might it be that something changed with the release on OutOfDate v1.3? It shouldn't be that but nothing else makes sense.

:rhelmer, yesterday when I ran the snippet in v 44.* with a profile that was created on 44.* version, then updated to 48 then opening again a 44.* version ( Components.utils.import("resource://gre/modules/AddonManager.jsm"); AddonManagerPrivate.backgroundUpdateCheck();) in a web console, I will get the result: "TypeError: Components.utils is undefined The Components object is deprecated. It will soon be removed."

Now, I don't seem to catch that result and the check is always triggered for all the Windows included in test run (win7, win 8.1, win10). I excluded the scenario in which it would behave different in browser console than in the web console or with the options Stephen suggested in comment 3.

A separate bug was logged for the Windows XP system addon check trigger: see Bug 1292562.

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to Adrian Florinescu [:AdrianSV] from comment #4)
> We can't reproduce the error we got yesterday when we were running the
> snippet on a profile that came from a higher than 44.
> Might it be that something changed with the release on OutOfDate v1.3? It
> shouldn't be that but nothing else makes sense.
> 
> :rhelmer, yesterday when I ran the snippet in v 44.* with a profile that was
> created on 44.* version, then updated to 48 then opening again a 44.*
> version (
> Components.utils.import("resource://gre/modules/AddonManager.jsm");
> AddonManagerPrivate.backgroundUpdateCheck();) in a web console, I will get
> the result: "TypeError: Components.utils is undefined The Components object
> is deprecated. It will soon be removed."


Is this the "web console" or the "browser console"? The former only runs with content privileges, the latter is needed to use things like Components.


> Now, I don't seem to catch that result and the check is always triggered for
> all the Windows included in test run (win7, win 8.1, win10). I excluded the
> scenario in which it would behave different in browser console than in the
> web console or with the options Stephen suggested in comment 3.
> 
> A separate bug was logged for the Windows XP system addon check trigger: see
> Bug 1292562.

Comment 6

[Adrian Florinescu [:aflorinescu]]

This cannot be reproduced anymore with using the browser console instead of web console.