Closed Bug 1756450 Opened 10 months ago Closed 2 months ago

some users report empty content for about:preferences#general (exceptions from unavailable services from app updater code)

Categories

(Toolkit :: Application Update, defect, P3)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
107 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- wontfix
firefox97 - wontfix
firefox98 - wontfix
firefox99 - wontfix
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- fixed

People

(Reporter: soeren.hentzschel, Assigned: bytesized)

References

(Blocks 1 open bug)

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [fidedi-ope])

Attachments

(10 files)

32.67 KB, image/jpeg
Details
30.23 KB, text/plain
Details
4.43 KB, text/plain
Details
95.67 KB, image/jpeg
Details
107.67 KB, image/jpeg
Details
3.87 KB, text/plain
Details
3.87 KB, text/plain
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

In the German Firefox support we got two reports from users who no longer see any content on about:preferences#general. But other preference panes work for these users.

Both users are on Windows 10, one user reported this issue after the update from Firefox 96 to Firefox 97 (user A), the other one after the update from Firefox ESR 91.5.1 to Firefox ESR 91.6.0 (user B).

From user B we got the information that installing Firefox ESR 91.5.1 again fixed the issue and updating to Firefox ESR 91.6.0 re-introduced the issue again.

From user A we got the following messages from the browser console:

4:46:02.286 1645105562285 addons.xpi WARN Checking C:\Program Files\Mozilla Firefox\distribution\extensions for addons

14:46:02.548 1645105562548 addons.webextension.screenshots@mozilla.org WARN Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: resource://pdf.js/

14:46:02.548 1645105562548 addons.webextension.screenshots@mozilla.org WARN Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: about:reader*

14:46:02.786 1645105562786 addons.webextension.screenshots@mozilla.org WARN Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: resource://pdf.js/

14:46:02.786 1645105562786 addons.webextension.screenshots@mozilla.org WARN Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: about:reader*

14:46:02.956 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:46:02.957 While creating services from category 'profile-after-change', could not create service for entry 'nsUpdateServiceStub', contract ID '@mozilla.org/updates/update-service-stub;1'

14:46:03.046 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:46:03.106 readUpdateConfig: Unable to read app update configuration file. Exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/FileUtils.jsm :: FileUtils_getDir :: line 63" data: no] 2 UpdateUtils.jsm:853

14:46:03.325 1645105563325 addons.webextension.jid1-MnnxcxisBPnSXQ@jetpack WARN Loading extension 'jid1-MnnxcxisBPnSXQ@jetpack': Reading manifest: Warning processing storage: An unexpected property was found in the WebExtension manifest.

14:46:04.585 Diese Seite befindet sich im Kompatibilitätsmodus (Quirks). Das Seitenlayout kann beeinflusst werden. Verwenden Sie für den Standardmodus "<!DOCTYPE html>".
sanitytest.html

14:46:04.611 Error: Can't find profile directory. 2 XULStore.jsm:66:15

14:46:06.723 readUpdateConfig: Unable to read app update configuration file. Exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/FileUtils.jsm :: FileUtils_getDir :: line 63" data: no] 2 UpdateUtils.jsm:853

14:46:08.414 1645105568414 app.normandy.action.PreferenceExperimentAction WARN Skipping recipe DoH Canada Preliminary because PreferenceExperimentAction was disabled during preExecution.

14:46:08.531 1645105568531 app.normandy.action.PreferenceExperimentAction WARN Skipping recipe Search Experiment: Measuring the Impacts of Different Search Providers because PreferenceExperimentAction was disabled during preExecution.

14:46:08.574 1645105568574 app.normandy.action.PreferenceExperimentAction WARN Skipping recipe Search Experiment: Measuring the Impacts of Different Search Providers - Part 2 because PreferenceExperimentAction was disabled during preExecution.

14:46:08.615 1645105568615 app.normandy.action.PreferenceExperimentAction WARN Skipping recipe Impact study for Total Cookie Protection (TCP) because PreferenceExperimentAction was disabled during preExecution.

14:46:09.698 1645105569698 app.normandy.action.BranchedAddonStudyAction WARN Skipping recipe DoH US Engagement Study V2 - Add-on helper because BranchedAddonStudyAction was disabled during preExecution.

14:46:45.260 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:46:45.262 Error initializing preference category paneGeneral: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 161" data: no] preferences.js:363

14:46:45.306 Uncaught (in promise)

Exception { name: "NS_ERROR_XPC_GS_RETURNED_FAILURE", message: "ServiceManager::GetService returned failure code:", result: 2153185302, filename: "resource://gre/modules/XPCOMUtils.jsm", lineNumber: 161, columnNumber: 0, data: null, stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isPending@resource:///modules/AppUpdater.jsm:114:1\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:164:5\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:58:20\ninit@chrome://browser/content/preferences/main.js:624:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\n", location: XPCWrappedNative_NoHelper }

XPCOMUtils.jsm:161

14:46:45.367 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:46:45.391 Uncaught (in promise)

Exception { name: "NS_ERROR_XPC_GS_RETURNED_FAILURE", message: "ServiceManager::GetService returned failure code:", result: 2153185302, filename: "resource://gre/modules/XPCOMUtils.jsm", lineNumber: 161, columnNumber: 0, data: null, stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isPending@resource:///modules/AppUpdater.jsm:114:1\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:164:5\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:58:20\ninit@chrome://browser/content/preferences/main.js:624:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\ninitializeCategories@chrome://browser/content/preferences/findInPage.js:108:26\ninit/</<@chrome://browser/content/preferences/findInPage.js:51:47\n", location: XPCWrappedNative_NoHelper }

XPCOMUtils.jsm:161

14:46:57.588 Tastenereignis ist in manchen Tastaturlayouts nicht verfügbar: Taste="i" Modifikatoren="accel,alt,shift" ID="key_browserToolbox" browser.xhtml

14:47:03.006 1645105623006 Toolkit.Telemetry WARN TelemetryController::_delayedInitTask - saveUninstallPing: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/TelemetryStorage.jsm :: getUninstallPingPath :: line 132" data: no] Stack trace: getUninstallPingPath()@resource://gre/modules/TelemetryStorage.jsm:132
removeUninstallPings()@resource://gre/modules/TelemetryStorage.jsm:2050
removeUninstallPings()@resource://gre/modules/TelemetryStorage.jsm:399
setupTelemetry/this._delayedInitTask<()@resource://gre/modules/TelemetryControllerParent.jsm:894

14:47:27.397 Error: Invalid autocomplete selectedIndex AutoCompleteChild.jsm:125:13

14:47:27.397 Error: Invalid autocomplete selectedIndex AutoCompleteChild.jsm:125:13

14:47:27.398 NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "Invalid autocomplete selectedIndex" {file: "resource://gre/actors/AutoCompleteChild.jsm" line: 125}]'[JavaScript Error: "Invalid autocomplete selectedIndex" {file: "resource://gre/actors/AutoCompleteChild.jsm" line: 125}]' when calling method: [nsIAutoCompletePopup::selectedIndex] LoginManagerChild.jsm:194

14:48:28.152 this.window.gBrowserInit is undefined ext-browser.js:1102

14:49:44.195 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:49:44.196 Error initializing preference category paneGeneral: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 161" data: no] preferences.js:363

14:49:44.229 Uncaught (in promise)

Exception { name: "NS_ERROR_XPC_GS_RETURNED_FAILURE", message: "ServiceManager::GetService returned failure code:", result: 2153185302, filename: "resource://gre/modules/XPCOMUtils.jsm", lineNumber: 161, columnNumber: 0, data: null, stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isPending@resource:///modules/AppUpdater.jsm:114:1\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:164:5\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:58:20\ninit@chrome://browser/content/preferences/main.js:624:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\n", location: XPCWrappedNative_NoHelper }

XPCOMUtils.jsm:161

14:49:44.280 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63

14:49:44.330 Uncaught (in promise)

Exception { name: "NS_ERROR_XPC_GS_RETURNED_FAILURE", message: "ServiceManager::GetService returned failure code:", result: 2153185302, filename: "resource://gre/modules/XPCOMUtils.jsm", lineNumber: 161, columnNumber: 0, data: null, stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isPending@resource:///modules/AppUpdater.jsm:114:1\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:164:5\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:58:20\ninit@chrome://browser/content/preferences/main.js:624:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\ninitializeCategories@chrome://browser/content/preferences/findInPage.js:108:26\ninit/</<@chrome://browser/content/preferences/findInPage.js:51:47\n", location: XPCWrappedNative_NoHelper }

XPCOMUtils.jsm:161

Not all of these console messages are relevant for the problem but "Error initializing preference category paneGeneral" looks very relevant.

I am not able to reproduce the issue but let me know if there is something I could ask the affected users.

Summary: some user report empty content for about:preferences#general → some users report empty content for about:preferences#general

[Tracking Requested - why for this release]:
Broken primary UI (prefs/settings)

This is very confusing. Nothing in the ESR pushlog looks at all related.

Looks like ryan says the pushlog should be:

https://hg.mozilla.org/releases/mozilla-esr91/pushloghtml?fromchange=FIREFOX_91_5_0esr_RELEASE&tochange=FIREFOX_91_6_0esr_RELEASE

So will look at that next.

The stack in comment 0:

XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30
get@resource://gre/modules/XPCOMUtils.jsm:62:51
get isPending@resource:///modules/AppUpdater.jsm:114:1
get isReadyForRestart@resource:///modules/AppUpdater.jsm:164:5
check@resource:///modules/AppUpdater.jsm:73:9
appUpdater@chrome://browser/content/aboutDialog-appUpdater.js:58:20
init@chrome://browser/content/preferences/main.js:624:21
init@chrome://browser/content/preferences/preferences.js:169:22

points at https://searchfox.org/mozilla-central/rev/211649f071259c4c733b4cafa94c44481c5caacc/browser/components/preferences/main.js#627 which then hits updater code. Over to updater. I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?

Severity: -- → S1
Flags: needinfo?(soeren.hentzschel)
OS: Unspecified → All
Priority: -- → P1
Hardware: Unspecified → Desktop

The ESR user said that he has a config-prefs.js file and setting general.config.obscure_value to 1 fixes the issue for him. I will forward the question regarding the about dialog (leaving the needinfo? request until I get a response).

(In reply to Sören Hentzschel from comment #4)

The ESR user said that he has a config-prefs.js file and setting general.config.obscure_value to 1 fixes the issue for him. I will forward the question regarding the about dialog (leaving the needinfo? request until I get a response).

Can they share the content of config-prefs.js ?

Component: Preferences → Application Update
Product: Firefox → Toolkit
Attached image config-prefs.jpg

I asked for the problematic value of general.config.obscure_value, will provide the answer ASAP.

Summary: some users report empty content for about:preferences#general → some users report empty content for about:preferences#general (exceptions from unavailable services from app updater code)

AFAICT the exception in comment #3 suggests that nsIUpdateManager is not available, ie this getter. But the call from the prefs is behind a AppConstants.MOZ_UPDATER check, so I don't understand why the service wouldn't be available. But the other errors in the log suggest that https://searchfox.org/mozilla-esr91/source/toolkit/mozapps/update/UpdateServiceStub.jsm failed to initialize which would perhaps explain that, and that it did so because the update root dir is not available from the directory service. I don't know why that would be the case.

My best guess right now is that bug 1732435 is somehow related, because it stops us using the maintenance service to create and/or fix permissions on the update directory, so if the user running Firefox can't do that themselves from their current privilege level, they have a bad time and the attempt to get the update dir from the update service can fail, which makes the update service fall over, which makes everything else fall over. Kirk, can you take a look if that is at all plausible?

Flags: needinfo?(bytesized)

(In reply to Sören Hentzschel from comment #7)

I asked for the problematic value of general.config.obscure_value, will provide the answer ASAP.

It happened with a value of 0. The user will check the about dialog tomorrow.

QA Whiteboard: [qa-regression-triage]

(In reply to :Gijs (he/him) from comment #3)

I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?

The ESR user checked the about dialog. Since the log from comment #0 was from another user (with Firefox 97) I asked the ESR user for the console output from both - opening the settings and the about dialog.

settings:

Error initializing preference category paneGeneral: TypeError: URL constructor:  is not a valid URL. preferences.js:277
    gotoPref chrome://browser/content/preferences/preferences.js:277
    AsyncFunctionThrow self-hosted:696
Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
    appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
    init chrome://browser/content/preferences/main.js:649
    init chrome://browser/content/preferences/preferences.js:105

Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
    appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
    init chrome://browser/content/preferences/main.js:649
    init chrome://browser/content/preferences/preferences.js:105
    initializeCategories chrome://browser/content/preferences/findInPage.js:96
    init chrome://browser/content/preferences/findInPage.js:52

about dialog:

Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bildschirm.uc.js
CustomizableUI is not defined bookmarks_backup_restore_button.uc.js:25
    <anonym> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/bookmarks_backup_restore_button.uc.js:25
    <anonym> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/bookmarks_backup_restore_button.uc.js:136
    loadScript file:///C:/Program Files (x86)/Mozilla Firefox/userChromeJS/utilities.js:89
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bookmarks_backup_restore_button.uc.js
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/ContextTranslate.uc.js
CustomizableUI is not defined downloadb.uc.js:21
    <anonym> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/downloadb.uc.js:21
    <anonym> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/downloadb.uc.js:66
    loadScript file:///C:/Program Files (x86)/Mozilla Firefox/userChromeJS/utilities.js:89
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/downloadb.uc.js
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/ExtendedCopy.uc.js
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/favicon_in_urlbar.uc.js
Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.
    appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
    init chrome://browser/content/aboutDialog.js:95
aboutDialog-appUpdater.js:47:19
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/fixsearchEngineIcon.uc.js
toggleImage
Uncaught TypeError: menu is null
    init file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/PasteAndGoForms.uc.js:17
    <anonymous> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/PasteAndGoForms.uc.js:102
    loadScript file:///C:/Program Files (x86)/Mozilla Firefox/userChromeJS/utilities.js:89
PasteAndGoForms.uc.js:17:5
    init file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/PasteAndGoForms.uc.js:17
    <anonym> file:///C:/Users/J311059/AppData/Roaming/Mozilla/Firefox/Profiles/grdehwju.default/chrome/PasteAndGoForms.uc.js:102
    loadScript file:///C:/Program Files (x86)/Mozilla Firefox/userChromeJS/utilities.js:89
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/printpreview.uc.js
Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/Schnelleinstellungen.uc.js
Flags: needinfo?(soeren.hentzschel)

Could not reproduce issue when upgrading from 96.0 to 97.0.1 I used a DE build, could not reproduce when upgrading from 91.5.1esr to 91.6.0 and using a DE build (also changed the value of general.config.obscure_value to 0 / 1, but about:preferences#general page loading without any issues).

(In reply to Sören Hentzschel from comment #11)

(In reply to :Gijs (he/him) from comment #3)

I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?

The ESR user checked the about dialog. Since the log from comment #0 was from another user (with Firefox 97) I asked the ESR user for the console output from both - opening the settings and the about dialog.

settings:

Error initializing preference category paneGeneral: TypeError: URL constructor:  is not a valid URL. preferences.js:277
    gotoPref chrome://browser/content/preferences/preferences.js:277
    AsyncFunctionThrow self-hosted:696
Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
    appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
    init chrome://browser/content/preferences/main.js:649
    init chrome://browser/content/preferences/preferences.js:105

OK, so this part is a dupe of bug 1754409 (already fixed in 99, I guess we can ask for uplift). They've customized the manual update URL via about:config or a custom prefs file and this is upsetting things. It's a regression from bug 1747293 which got uplifted.

Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bildschirm.uc.js
CustomizableUI is not defined bookmarks_backup_restore_button.uc.js:25

Uh, so they're running custom user chrome scripts that they or someone else wrote and those are breaking. I can't help with that.

At this point this bug is pretty confusing because it would appear that the two reports are not necessarily related. I'm confident that your last comment is from someone who is seeing the exact same thing as bug 1754409. They can work around locally by making the manual update URL something that does parse as a URL. This comment from Kirk seems apt to me:

(Kirk Steuber (he/him) [:bytesized] from bug 1754409 comment #2)

(In reply to Tynth from comment #0)

Normally i delete URL for option app.update.url.manual

Why do you want to be able to do this? I can't think of any reason to. It seems like the only real change this would cause is to break the link that Firefox shows you if an update fails. But if you don't want to use the link, can't you just not click on it? Why is it necessary to break it?

It's kind of inevitable that if you screw up your prefs enough, it will break things. And I would consider removing the manual update URL to be a form of screwing up your prefs.

Anyway, the logs in comment 0 (from the user on 97) do not really match the same issue, AFAICT. Do we have any more details from that user? The list of possible causes there is significantly longer because there were obviously more changes between 96 and 97. If the user can reproduce the problem with mozregression, that would be much the quickest way of finding out what the cause of their issue is. AFAICT their browser has no idea where to put updates, and this is breaking all sorts of things, including telemetry and (I'm guessing) further updates, so it seems pretty important to still find out what is going on there.

Flags: needinfo?(soeren.hentzschel)

It seems to me that we should probably try to make things more robust/fault-tolerant here even if there is something wacky going on with the prefs.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)

It seems to me that we should probably try to make things more robust/fault-tolerant here even if there is something wacky going on with the prefs.

FWIW, I think the wacky prefs thing is what's hitting the ESR user, and is covered by bug 1754409 which is already fixed in 99; we should cover any beta/esr uplift requests there. Ryan, are you OK driving that?

I'd like to use this bug to work out what's up with the 96-97 user's errors from comment 0 ("user A"), as they look different, so I suspect are a separate issue.

Flags: needinfo?(ryanvm)

(In reply to :Gijs (he/him) from comment #15)

FWIW, I think the wacky prefs thing is what's hitting the ESR user, and is covered by bug 1754409 which is already fixed in 99; we should cover any beta/esr uplift requests there. Ryan, are you OK driving that?

Looks like Pascal's on top of that already! But yeah, that looks very safe to uplift and I'll leave it on the radar for a possibly 97 dot release ride-along too should the need arise.

Flags: needinfo?(ryanvm)
See Also: → 1754409

(In reply to :Gijs (he/him) from comment #9)

My best guess right now is that bug 1732435 is somehow related, because it stops us using the maintenance service to create and/or fix permissions on the update directory, so if the user running Firefox can't do that themselves from their current privilege level, they have a bad time and the attempt to get the update dir from the update service can fail, which makes the update service fall over, which makes everything else fall over. Kirk, can you take a look if that is at all plausible?

It seems unlikely to me that this problem is happening because of the inability to fix the permissions. Bad permissions and an inability to fix them are a problem that we've had to deal with prior to Bug 1732435 and we generally show the "manual update doorhanger" successfully in that case.

(In reply to :Gijs (he/him) from comment #8)

... the other errors in the log suggest that https://searchfox.org/mozilla-esr91/source/toolkit/mozapps/update/UpdateServiceStub.jsm failed to initialize which would perhaps explain that, and that it did so because the update root dir is not available from the directory service. I don't know why that would be the case.

If we couldn't get the update root directory, that seems likely to cause some pretty serious problems. It seems quite possible that it could cause the ones being described here. I took a look through the patch that changes this code, but nothing really stands out as problematic. It doesn't help though that it is a pretty long patch and, since we don't know how to reproduce this problem, I don't really know what I'm looking for.

If anyone can find a way to reproduce this, I'd be happy to debug further.

Flags: needinfo?(bytesized)

(In reply to :Gijs (he/him) from comment #13)

OK, so this part is a dupe of bug 1754409 (already fixed in 99, I guess we can ask for uplift). They've customized the manual update URL via about:config or a custom prefs file and this is upsetting things. It's a regression from bug 1747293 which got uplifted.

The ESR user confirmed that this was the reason for him. Thanks!

(In reply to :Gijs (he/him) from comment #13)

Anyway, the logs in comment 0 (from the user on 97) do not really match the same issue, AFAICT. Do we have any more details from that user?

Unfortunately the user did not respond yet. We asked the user for his about:support content when he was still responsive but about:support was broken for him as well (most fields were empty, including modified preferences) . I'll report back if we get more information from this user.

I'm going to go ahead and reduce the priority and severity here.

P1 isn't really right since we aren't working on fixing this for this cycle. That is something that we would likely do if we could reproduce this, or at least were in contact with a user that could reproduce this. But we can't and we aren't. We will revise the priority again when we get enough information for this to be actionable.

S1 isn't really right here either. There is major functionality impaired here, but it doesn't really rise to "catastrophic" levels, particularly given the low number of users that this is known to affect.

Severity: S1 → S2
Priority: P3 → --
Priority: -- → P3

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Priority: P3 → P2

A little confused about what this bot is doing. The linked page doesn't really explain why it did that. Relman can track this all they want, but the fact of the matter is that we cannot even start work on this until we have some way of digging into what the problem is. Until that changes, we cannot plan on getting this fixed in the next few cycles.

Priority: P2 → P3

Given what we know about the issue at this point, I don't think we need to track it.

Flags: needinfo?(soeren.hentzschel)

:bhearsum is this still considered an S2, if so do we expect a fix in the medium term or is it an S3?

Flags: needinfo?(bhearsum)

(In reply to Donal Meehan [:dmeehan] from comment #23)

:bhearsum is this still considered an S2, if so do we expect a fix in the medium term or is it an S3?

As far as I know, this is not actionable at the moment because we can't reproduce it. If you want to move to S3 because of that, I'm good with it. (I didn't do it myself because it seemed not to align with the spirit of S3.)

Flags: needinfo?(bhearsum)
Severity: S2 → S3

Hi,

I also have this issue in my two different computers, that in 96.0.3 I could normally see about:preferences#general but after updating to 97.0 or newer, that page won't show anything anymore. If I'll write something in that search field, it will show me the content but I can't do any changes.

I have removed and re-installed Firefox totally several times (also using Revo Uninstaller to remove all left-overs) but it didn't help. I have tried different language versions, no help. I then tested the latest ESR version - it worked just fine. I removed that and installed 96.0.3 again. Everything still fine. But as soon as it auto-updated to latest version (currently 102.0.1), that about:preferences#general page is again empty. In browse console I can see different error messages.

I'm using 64-bit version of Firefox and my Windows 10 is in English. This problem has been there as long as the 97.0 had published. After that there has been several udates to Windows but they have not helped.

One observation also: I recently installed one new computer using Windows 11. I also installed Firefox to that computer but there everything worked just fine. So it seems, in clean installed computers there're no problems to show that #general page. So could it be, that some earlier version of Mozilla has done some changes to Windows registry or files which is now causing this problem? Or is there some other program which is the root cause for this?

I got these different errors while trying to open about:perefences#general:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]

Error initializing preference category paneGeneral: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 161" data: no]

Uncaught (in promise)

--

I read this threat through and see some suggestion which could be the root cause. Unfortunately none of them is suitable for me. I have not manually modified that app.update.url.manual parameter and I don't have created manually that config-prefs.js file.

Br,
Janne

(In reply to Janne from comment #25)

Hi,

I also have this issue in my two different computers, that in 96.0.3 I could normally see about:preferences#general but after updating to 97.0 or newer, that page won't show anything anymore. If I'll write something in that search field, it will show me the content but I can't do any changes.

Thanks for sharing and helping us get to the bottom of this!

I got these different errors while trying to open about:perefences#general:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]

Error initializing preference category paneGeneral: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 161" data: no]

Uncaught (in promise)

For all of these, would you mind clicking the little expander arrow at the start of the line to show the entire stack of the error, and then copy-pasting that here, so we get the filenames and line numbers? On their own, unfortunately these don't give us enough information to narrow down what is broken. It'd be best to get this info from the most recent release (currently 102, 103 will come out next week) if possible.

Also, on the machine + Firefox profile where this reproduces, could you go to about:support, hit the "copy raw data" button, and paste the contents here to attach them to this bug?

Thank you!

Flags: needinfo?(jjsilvo)

Hi,

These are expanded error messages (I only opened the first arrow at this time). Tell me if I need to expand all possible arrows. The current version is 102.0.1 (64-bit):

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63
FileUtils_getDir resource://gre/modules/FileUtils.jsm:63
getUpdateDirCreate resource://gre/modules/UpdateService.jsm:1014
getUpdateFile resource://gre/modules/UpdateService.jsm:1053
UM__loadXMLFileIntoArray resource://gre/modules/UpdateService.jsm:4100
UpdateManager resource://gre/modules/UpdateService.jsm:3995
XPCU_serviceLambda resource://gre/modules/XPCOMUtils.jsm:161
get resource://gre/modules/XPCOMUtils.jsm:62
get isReadyForRestart resource:///modules/AppUpdater.jsm:156
check resource:///modules/AppUpdater.jsm:73
appUpdater chrome://browser/content/aboutDialog-appUpdater.js:62
init chrome://browser/content/preferences/main.js:634
init chrome://browser/content/preferences/preferences.js:169
init_category_if_required chrome://browser/content/preferences/preferences.js:145
gotoPref chrome://browser/content/preferences/preferences.js:372
init_all chrome://browser/content/preferences/preferences.js:226
_fireOnSelect chrome://global/content/elements/richlistbox.js:332
selectItem chrome://global/content/elements/richlistbox.js:463
MozRichlistitem chrome://global/content/elements/richlistbox.js:888
Error initializing preference category paneGeneral: [Exception... "ServiceManager::GetService returned failure code:" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 161" data: no] preferences.js:375
gotoPref chrome://browser/content/preferences/preferences.js:375
AsyncFunctionThrow self-hosted:636
Uncaught (in promise)
Exception { name: "NS_ERROR_XPC_GS_RETURNED_FAILURE", message: "ServiceManager::GetService returned failure code:", result: 2153185302, filename: "resource://gre/modules/XPCOMUtils.jsm", lineNumber: 161, columnNumber: 0, data: null, stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:156:18\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:62:20\ninit@chrome://browser/content/preferences/main.js:634:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\ninit_category_if_required@chrome://browser/content/preferences/preferences.js:145:23\ngotoPref@chrome://browser/content/preferences/preferences.js:372:11\ninit_all/<@chrome://browser/content/preferences/preferences.js:226:58\n_fireOnSelect@chrome://global/content/elements/richlistbox.js:332:12\nselectItem@chrome://global/content/elements/richlistbox.js:463:12\nMozRichlistitem/<@chrome://global/content/elements/richlistbox.js:888:21\n", location: XPCWrappedNative_NoHelper }

columnNumber: 0

data: null

filename: "resource://gre/modules/XPCOMUtils.jsm"

lineNumber: 161

location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }

message: "ServiceManager::GetService returned failure code:"

name: "NS_ERROR_XPC_GS_RETURNED_FAILURE"

result: 2153185302

stack: "XPCU_serviceLambda@resource://gre/modules/XPCOMUtils.jsm:161:30\nget@resource://gre/modules/XPCOMUtils.jsm:62:51\nget isReadyForRestart@resource:///modules/AppUpdater.jsm:156:18\ncheck@resource:///modules/AppUpdater.jsm:73:9\nappUpdater@chrome://browser/content/aboutDialog-appUpdater.js:62:20\ninit@chrome://browser/content/preferences/main.js:634:21\ninit@chrome://browser/content/preferences/preferences.js:169:22\ninit_category_if_required@chrome://browser/content/preferences/preferences.js:145:23\ngotoPref@chrome://browser/content/preferences/preferences.js:372:11\ninit_all/<@chrome://browser/content/preferences/preferences.js:226:58\n_fireOnSelect@chrome://global/content/elements/richlistbox.js:332:12\nselectItem@chrome://global/content/elements/richlistbox.js:463:12\nMozRichlistitem/<@chrome://global/content/elements/richlistbox.js:888:21\n"

<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
XPCOMUtils.jsm:161

--

Br,
Janne

Flags: needinfo?(jjsilvo)

Janne: thanks, that looks very useful off-hand!

Kirk, are the tracebacks in comment #27 (and the attached about:support data) sufficient for you to figure out what's happening, and/or do you need more information here?

Flags: needinfo?(bytesized)

It looks like about:preferences tries to load the AppUpdater, which tries to load the UpdateManager. And the UpdateManager is not loaded successfully because its initialization reads from the update directory, which it fails to get the path to.

It seems like the most recent stack frame, where the exception originates, is here. This doesn't seem quite right though, since the exception claims to be coming from nsIProperties.get. So I'm guessing that the error is actually coming from this line. I'm not really clear on why the line numbers don't quite match.

The call to FileUtils.getDir is passing in UpdRootD. So the fact that the directory service is responding with NS_ERROR_FAILURE seems to indicate that the update directory isn't registered with it. I'm not really familiar with the inner workings of the directory service, but I'm guessing that there is no entry for UpdRootD in the nsIProperties interface because the UpdRootD getter is returning an error.

@Mossop Since the function that generates the update directory name is fairly opaque, the only way that I can think of to dig deeper into this issue is to have the reporter run a custom Firefox build with a ton of logging added to that function. Before I go down that road, I wanted to ask you (a) Do you know if my guess for why there is no UpdRootD entry seems good? Or, if you don't know, do you know who to ask about that? (b) Can you think of any better ways to investigate this issue before I start working on a custom build?

Flags: needinfo?(bytesized) → needinfo?(dtownsend)

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #30)

It looks like about:preferences tries to load the AppUpdater, which tries to load the UpdateManager. And the UpdateManager is not loaded successfully because its initialization reads from the update directory, which it fails to get the path to.

It seems like the most recent stack frame, where the exception originates, is here. This doesn't seem quite right though, since the exception claims to be coming from nsIProperties.get. So I'm guessing that the error is actually coming from this line. I'm not really clear on why the line numbers don't quite match.

The call to FileUtils.getDir is passing in UpdRootD. So the fact that the directory service is responding with NS_ERROR_FAILURE seems to indicate that the update directory isn't registered with it. I'm not really familiar with the inner workings of the directory service, but I'm guessing that there is no entry for UpdRootD in the nsIProperties interface because the UpdRootD getter is returning an error.

@Mossop Since the function that generates the update directory name is fairly opaque, the only way that I can think of to dig deeper into this issue is to have the reporter run a custom Firefox build with a ton of logging added to that function. Before I go down that road, I wanted to ask you (a) Do you know if my guess for why there is no UpdRootD entry seems good? Or, if you don't know, do you know who to ask about that? (b) Can you think of any better ways to investigate this issue before I start working on a custom build?

I wonder if you could use the Browser Console to verify that Services.dirsvc.get("UpdRootD", Ci.nsIFile) is actually failing? And then start copy-pasting code blocks to narrow the issue?

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #30)

I'm not really clear on why the line numbers don't quite match.

If I had to guess, we've already merged 103 to mozilla-release (as it's shipping next week) and that's what searchfox is showing you, but the reporter was using 102. If you check ESR-102 on searchfox, the line number matches: https://searchfox.org/mozilla-esr102/rev/7e61070c9bb9030d20f75aa09a2b0ebb662ed2a0/toolkit/modules/FileUtils.jsm#63

(In reply to Nick Alexander :nalexander [he/him] from comment #31)

I wonder if you could use the Browser Console to verify that Services.dirsvc.get("UpdRootD", Ci.nsIFile) is actually failing?

Yeah, let's start with this.

@Janne - Can you try this and let me know what happens?

  1. Check that about:preferences#general is still experiencing the same problem.
  2. Enable running commands in the Browser Console by navigating to about:config and setting devtools.chrome.enabled to true.
  3. Open the Browser Console, either via Control+Shift+J or Hamburger Menu->More Tools->Browser Console.
  4. Run these two commands, one at a time, and let me know what output you get for each. For the first command, if there is an error or traceback, I'd like you to expand it so that I can see precisely what is going wrong. If it returns something like XPCWrappedNative_NoHelper, you don't need to expand it; I don't need to see all the details of that.
Services.dirsvc.get("UpdRootD", Ci.nsIFile)
Services.dirsvc.get("UpdRootD", Ci.nsIFile).path

If those commands run successfully, then I must not have properly identified where the problem is coming from, and we'll have to dig a bit deeper to figure out what's going on. If they do not run successfully, then one of two things is happening: either the directory service isn't retrieving the update directory at all for some reason, or we are failing to generate the update directory path. In this case, I'll try to look a bit deeper into the directory service to see if there is something we can do to identify which of those two things is actually happening. But I think that it's quite likely that I'll have to create a custom build that produces more logging so that we can identify the issue.

Flags: needinfo?(dtownsend) → needinfo?(jjsilvo)

Hi,

Yes, the same problem still occurs in about:preferences#general page and the Firefox version is still 102.0.1.

I enabled that parameter in about:config and ran then those commands in Browser Console window.

--

Here's the output of that first command:

Services.dirsvc.get("UpdRootD", Ci.nsIFile)
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]", result: 2147500037, filename: "debugger eval code", lineNumber: 1, columnNumber: 0, data: null, stack: "@debugger eval code:1:17\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n", location: XPCWrappedNative_NoHelper }

columnNumber: 0

data: null

filename: "debugger eval code"

lineNumber: 1

location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }

message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"

name: "NS_ERROR_FAILURE"

result: 2147500037

stack: "@debugger eval code:1:17\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n"

<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }


and here's from the second one:

Services.dirsvc.get("UpdRootD", Ci.nsIFile).path
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]", result: 2147500037, filename: "debugger eval code", lineNumber: 1, columnNumber: 0, data: null, stack: "@debugger eval code:1:17\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n", location: XPCWrappedNative_NoHelper }

columnNumber: 0

data: null

filename: "debugger eval code"

lineNumber: 1

location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }

message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"

name: "NS_ERROR_FAILURE"

result: 2147500037

stack: "@debugger eval code:1:17\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n"

<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
debugger eval code:1:17

​--

I'm not sure did I expanded they enough or not...

Br,
Janne

Flags: needinfo?(jjsilvo)

Alright, I've built a custom build of Firefox that adds a bunch more logging that will hopefully help us get to the bottom of this.

  1. First, you'll want to download and install the custom build here. Note that because this isn't an official Mozilla build, this isn't properly signed, so Windows will warn you that it was created by an "Unknown Publisher". If you already have Firefox Nightly installed, you should probably hit the "Custom" setup type and choose a different directory to install into. Otherwise it will overwrite your existing Firefox Nightly installation.
  2. Run the custom build and make sure that we can still reproduce the problem. That is to say, make sure that about:preferences#general doesn't display correctly.
  3. Enable running commands in the Browser Console by navigating to about:config and setting devtools.chrome.enabled to true.
  4. Open the Browser Console, either via Control+Shift+J or Hamburger Menu->More Tools->Browser Console.
  5. Run this line of code:
Cc["@mozilla.org/xre/directory-provider;1"].getService(Ci.nsIDirectoryServiceProvider).getUpdateDir();

I'm guessing that this line of code will fail. If it does not, then I have incorrectly identified the source of the problem, and it is likely somewhere within the Directory Service, in which case I will probably have to redirect the debugging to someone that is more familiar with how the Directory Service works.

Assuming that it does fail, this custom build will have written some detailed logging that should help me understand what is going on. You should be able to find it by opening the File Explorer and typing %ProgramData% into the location bar at the top. There you should be able to find a file called firefox-custom-build-log.txt. Please attach that log to this bug.

When you are done, you probably want to uninstall custom Firefox build.

Flags: needinfo?(jjsilvo)
Hi,

I just installed that custom build and the same problem still occurred there with about:preferences#general. I then enabled that parameter and ran that command. Here's the output:

Hi,

I just installed that custom build and the same problem still occurred there with about:preferences#general. I then enabled that parameter and ran that command. Here's the output:

Cc["@mozilla.org/xre/directory-provider;1"].getService(Ci.nsIDirectoryServiceProvider).getUpdateDir();
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDirectoryServiceProvider.getUpdateDir]", result: 2147500037, filename: "debugger eval code", lineNumber: 1, columnNumber: 0, data: null, stack: "@debugger eval code:1:88\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n", location: XPCWrappedNative_NoHelper }

columnNumber: 0

data: null

filename: "debugger eval code"

lineNumber: 1

location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }

message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDirectoryServiceProvider.getUpdateDir]"

name: "NS_ERROR_FAILURE"

result: 2147500037

stack: "@debugger eval code:1:88\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n"

<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
debugger eval code:1:88
<anonymous> debugger eval code:1
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:59
FileUtils_getDir resource://gre/modules/FileUtils.jsm:59
getUpdateDirCreate resource://gre/modules/UpdateService.jsm:1013
getUpdateFile resource://gre/modules/UpdateService.jsm:1052
UM__loadXMLFileIntoArray resource://gre/modules/UpdateService.jsm:4117
UpdateManager resource://gre/modules/UpdateService.jsm:4012
XPCU_serviceLambda resource://gre/modules/XPCOMUtils.sys.mjs:156
get resource://gre/modules/XPCOMUtils.sys.mjs:57
get _pingSuffix resource://gre/modules/UpdateService.jsm:3126
AUS__checkForBackgroundUpdates resource://gre/modules/UpdateService.jsm:3169
AUS_notify resource://gre/modules/UpdateService.jsm:3114
TM_notify resource://gre/modules/UpdateTimerManager.jsm:224
TM_notify resource://gre/modules/UpdateTimerManager.jsm:295
NS_ERROR_XPC_GS_RETURNED_FAILURE: ServiceManager::GetService returned failure code: XPCOMUtils.sys.mjs:156
XPCU_serviceLambda resource://gre/modules/XPCOMUtils.sys.mjs:156
get resource://gre/modules/XPCOMUtils.sys.mjs:57
get _pingSuffix resource://gre/modules/UpdateService.jsm:3126
AUS__checkForBackgroundUpdates resource://gre/modules/UpdateService.jsm:3169
AUS_notify resource://gre/modules/UpdateService.jsm:3114
TM_notify resource://gre/modules/UpdateTimerManager.jsm:224
TM_notify resource://gre/modules/UpdateTimerManager.jsm:295
1659113984989 Toolkit.Telemetry WARN TelemetryController::_delayedInitTask - saveUninstallPing failed: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/TelemetryStorage.jsm :: getUninstallPingPath :: line 133" data: no] Stack trace: getUninstallPingPath()@resource://gre/modules/TelemetryStorage.jsm:133
removeUninstallPings()@resource://gre/modules/TelemetryStorage.jsm:2056
saveUninstallPing()@resource://gre/modules/TelemetryStorage.jsm:2043
saveUninstallPing()@resource://gre/modules/TelemetryStorage.jsm:389
saveUninstallPing()@resource://gre/modules/TelemetryControllerParent.jsm:744
setupTelemetry/this._delayedInitTask<()@resource://gre/modules/TelemetryControllerParent.jsm:894
<Provider> does not support changing store on the fly. It is most likely that you see this error because you updated to Redux 2.x and React Redux 2.x which no longer hot reload reducers automatically. See https://github.com/reactjs/react-redux/releases/tag/v2.0.0 for the migration instructions. react-redux.js:881:13

​--

I'll upload that detailed logging little bit later.

Br,
Janne

Hmm, I couldn't find that log file firefox-custom-build-log.txt in %ProgramData%.

Br,
Janne

Flags: needinfo?(jjsilvo)

Sorry, I've been out sick. But I'm back now!

(In reply to Janne from comment #38)

Hmm, I couldn't find that log file firefox-custom-build-log.txt in %ProgramData%.

That is extremely unfortunate. It seems to strongly suggest that the problem that we are having is properly finding the program data directory. Could you go to the %ProgramData% directory and then tell me what path that is? The usual path is C:\ProgramData\. But I think that it might be called something else in different languages of Windows.

Flags: needinfo?(jjsilvo)

Hi,

It's exactly that C:\ProgramData, just checked. My W10 is in English.

I also tried that debug twice but same problem both times. Between those tests I fully uninstalled and re-installed that custom build. No difference.

I also seached through my directories for that firefox-custom-build-log.txt, but it didn't exist anywhere.

Could it be that since this is from "unknown publisher", Windows will prevent writing to %ProgramData%? Could it be possible to change the destination folder for that debug file for example to Mozilla folder?

I have Norton 360 but during those tests I disabled it to be sure, it won't cause the issue with that debug file.

Br,
Janne

Flags: needinfo?(jjsilvo)

(In reply to Janne from comment #40)

Could it be that since this is from "unknown publisher", Windows will prevent writing to %ProgramData%? Could it be possible to change the destination folder for that debug file for example to Mozilla folder?

I don't think so. I'm pretty sure that the "unknown publisher" thing just changes the installation, I don't think it limits the program once it is installed. And it worked fine on my machine.

Could it be possible to change the destination folder for that debug file for example to Mozilla folder?

I'm not sure which Mozilla folder you mean. Do you mean the one in ProgramData? We could try it, but I don't know of any reason why that would work and this wouldn't. That folder isn't created by any elevated code. It's created by the same code that is doing the logging here.

I'm wondering if the problem is that the code that I added logging to never actually gets executed. I think I want to add some logging a bit earlier in the process. But I want to make sure that I'm putting it somewhere that we will be able to write to successfully. If you have a folder in mind that you know we could write to successfully, let me know where you would like the log file to go. Otherwise, I'll probably try hard coding the current update directory location, which should be C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\. Can you please either check that that directory already exists or tell me the path of a different directory that I can have it put the log file in?

Thanks!

Flags: needinfo?(jjsilvo)

My best guess is that the reason that no log was created is that we weren't hitting the code that I added logging to. This time, I added more logging, running right up to the XPCOM boundary (where the tracebacks end because the code switches from JS to C++). Just in case the log doesn't get written out, I have also changed around the error codes so that hopefully this time we get a more informative error code than the NS_ERROR_FAILURE that we were getting before.

@Janne - Could you try again with this new build and see if (a) the log is created and (b) what error code it gives you this time?

Thanks!

Hi,

I tested it again with that latest custom build, but still the same problem. After running that code, none log file is found. You asked earlier what I mean by using Mozilla directory to save the debug file. I mean eg. C:\Program Files\Firefox Nightly\ or something. So it wouldn't go under ProgramData.

I noticed, that Norton gave somekind of warning while installing the custom build. I'll send it as an attachment.

And am I running the code correctly when I'm pasting it to that Browser Console after those >> marks?

Br,
Janne

Flags: needinfo?(jjsilvo)
Attached file error message
This is the error message expanded:

This is the error message expanded:

Uncaught
Exception { name: "", message: "Component returned failure code: 0x80720019 [nsIDirectoryServiceProvider.getUpdateDir]", result: 2154954777, filename: "debugger eval code", lineNumber: 1, columnNumber: 0, data: null, stack: "@debugger eval code:1:88\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n", location: XPCWrappedNative_NoHelper }

columnNumber: 0

data: null

filename: "debugger eval code"

lineNumber: 1

location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
​​
QueryInterface: function QueryInterface()
​​
asyncCaller: null
​​
asyncCause: null
​​
caller: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename:
, name:
, … }
​​
columnNumber: 88
​​
filename: "debugger eval code"
​​
formattedStack: "@debugger eval code:1:88\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n"
​​
lineNumber: 1
​​
name: null
​​
nativeSavedFrame: SavedFrame { source: "debugger eval code", sourceId: 2150, line: 1, … }
​​
sourceId: 2150
​​
sourceLine: ""
​​
toString: function toString()
​​
<get asyncCaller()>: function asyncCaller()
​​
<get asyncCause()>: function asyncCause()
​​
<get caller()>: function caller()
​​
<get columnNumber()>: function columnNumber()
​​
<get filename()>: function filename()
​​
<get formattedStack()>: function formattedStack()
​​
<get lineNumber()>: function lineNumber()
​​
<get name()>: function name()
​​
<get nativeSavedFrame()>: function nativeSavedFrame()
​​
<get sourceId()>: function sourceId()
​​
<get sourceLine()>: function sourceLine()
​​
<prototype>: Object { … }

message: "Component returned failure code: 0x80720019 [nsIDirectoryServiceProvider.getUpdateDir]"

name: ""

result: 2154954777

stack: "@debugger eval code:1:88\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1118:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1010:35\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n"

<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
​​
columnNumber:
​​
data:
​​
filename:
​​
lineNumber:
​​
location:
​​
message:
​​
name:
​​
result:
​​
stack:
​​
toString: function toString()
​​
Symbol(Symbol.toStringTag): "Exception"
​​
<get columnNumber()>: function columnNumber()
​​
<get data()>: function data()
​​
<get filename()>: function filename()
​​
<get lineNumber()>: function lineNumber()
​​
<get location()>: function location()
​​
<get message()>: function message()
​​
<get name()>: function name()
​​
<get result()>: function result()
​​
<get stack()>: function stack()
​​
<set stack()>: function stack()
​​
<prototype>: Object { … }

(In reply to Janne from comment #43)

Hi,

I tested it again with that latest custom build, but still the same problem. After running that code, none log file is found. You asked earlier what I mean by using Mozilla directory to save the debug file. I mean eg. C:\Program Files\Firefox Nightly\ or something. So it wouldn't go under ProgramData.

Oh, I definitely can't save the log file there. Firefox doesn't have permission to write to Program Files. There are security reasons why regular, unelevated processes can't write there. The installer can only write there because it elevates its permissions (causing the User Account Control prompt). The updater can write there because the installer uses its elevated permissions to install the Mozilla Maintenance Service, whose entire purpose is to grant the updater elevated privileges without a UAC prompt.

I noticed, that Norton gave somekind of warning while installing the custom build. I'll send it as an attachment.

Hmm. That antivirus thing is curious, but I don't think it's a problem. It looks like it just doesn't want the installer installing a shortcut for some reason. I'm not really sure why. Maybe because the installer is not signed properly? Hard to say.

And am I running the code correctly when I'm pasting it to that Browser Console after those >> marks?

From the screenshot, it looks to me like you are doing the right thing.


Oh. Now that I have taken a look at the modified error code that has been returned, I think I can explain every problem that is going on at once. The error is coming from the part of the code that creates the update directory. I am guessing that this also explains why the log file isn't being written out. I suspect that ProgramData has odd permissions that are preventing us from writing there. Could you run these commands to check the permissions for me? First, open a command prompt by using Command+R, typing cmd, and pressing Enter. Then run these two commands, which will print out the permissions of those two directories.

icacls C:\ProgramData
icacls "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38"

For example, my permissions look like this:

C:\Users\bytesized>icacls "C:\ProgramData"
C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)(F)
               BUILTIN\Administrators:(OI)(CI)(F)
               CREATOR OWNER:(OI)(CI)(IO)(F)
               BUILTIN\Users:(OI)(CI)(RX)
               BUILTIN\Users:(CI)(WD,AD,WEA,WA)

Successfully processed 1 files; Failed processing 0 files

C:\Users\bytesized>icacls "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38"
C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38 BUILTIN\Users:(OI)(CI)(F)
                                                            BUILTIN\Administrators:(OI)(CI)(F)
                                                            NT AUTHORITY\SYSTEM:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

It is quite possible that, since we are failing to create the Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38 directory, the latter command will simply say The system cannot find the file specified.. But I'd like to check just in case.

Flags: needinfo?(jjsilvo)

Oh, one other question. Do you have any idea how the permissions on ProgramData would have gotten messed up? Do you remember ever changing them manually, for instance? It also seems possible that some rude program did it. But, if it did, I'm guessing that you have no idea which one.

Hi,

The permissions looks different in my system:

C:\Users\habbe>icacls C:\ProgramData
C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)

Successfully processed 1 files; Failed processing 0 files

C:\Users\habbe>icacls "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38"
C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38: The system cannot find the file specified.
Successfully processed 0 files; Failed processing 1 files

C:\Users\habbe>

I have no idea what could have changed those permissions... I'll run system check to see, will it change anything. But could it be, that this would actually be the root cause for the original problem with about:preferences#general not shown correctly?

Br,
Janne

Flags: needinfo?(jjsilvo)

I think I managed to fix this! I just gave command:

icacls "c:\ProgramData" /reset /T /C

and once that has finished, I downloaded and installer the official Firefox 103.0.2 (64-bit). Now I can correctly see about:preferences#general and browser console won't show errors.

So it strongly seems, that incorrect permissions for ProgramData directory was the root cause. And that command above reset those permissions.

Yes, it's working now. I also test with that custom build and about:preferences#general is working correctly. While giving that command, it won't return error(s) anymore:

Cc["@mozilla.org/xre/directory-provider;1"].getService(Ci.nsIDirectoryServiceProvider).getUpdateDir();
XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), append: append(), normalize: normalize(), create: create(), leafName: Getter & Setter, displayName: Getter, copyTo: copyTo(), copyToFollowingLinks: copyToFollowingLinks(), moveTo: moveTo(), moveToFollowingLinks: moveToFollowingLinks(), … }

DELETE_ON_CLOSE: 2147483648

DIRECTORY_TYPE: 1

NORMAL_FILE_TYPE: 0

OS_READAHEAD: 1073741824

QueryInterface: function QueryInterface()

append: function append()

appendRelativePath: function appendRelativePath()

clone: function clone()

contains: function contains()

copyTo: function copyTo()

copyToFollowingLinks: function copyToFollowingLinks()

create: function create()

createUnique: function createUnique()

creationTime: 1660240073662

creationTimeOfLink: 1660240073662

directoryEntries: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), entries: entries(), hasMoreElements: hasMoreElements(), … }

diskCapacity: 498964885504

diskSpaceAvailable: 308839165952

displayName: "6F193CCC56814779"

equals: function equals()

exists: function exists()

fileSize: 0

fileSizeOfLink: 0

getRelativeDescriptor: function getRelativeDescriptor()

getRelativePath: function getRelativePath()

initWithFile: function initWithFile()

initWithPath: function initWithPath()

isDirectory: function isDirectory()

isExecutable: function isExecutable()

isFile: function isFile()

isHidden: function isHidden()

isReadable: function isReadable()

isSpecial: function isSpecial()

isSymlink: function isSymlink()

isWritable: function isWritable()

lastModifiedTime: 1660240168440

lastModifiedTimeOfLink: 1660240168440

launch: function launch()

leafName: "6F193CCC56814779"

moveTo: function moveTo()

moveToFollowingLinks: function moveToFollowingLinks()

normalize: function normalize()

parent: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), append: append(), normalize: normalize(), … }

path: "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\6F193CCC56814779"

permissions: 438

permissionsOfLink: 438

persistentDescriptor: "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\6F193CCC56814779"

remove: function remove()

renameTo: function renameTo()

reveal: function reveal()

setRelativeDescriptor: function setRelativeDescriptor()

setRelativePath: function setRelativePath()

target: "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\6F193CCC56814779"

<get creationTime()>: function creationTime()

<get creationTimeOfLink()>: function creationTimeOfLink()

<get directoryEntries()>: function directoryEntries()

<get diskCapacity()>: function diskCapacity()

<get diskSpaceAvailable()>: function diskSpaceAvailable()

<get displayName()>: function displayName()

<get fileSize()>: function fileSize()

<set fileSize()>: function fileSize()

<get fileSizeOfLink()>: function fileSizeOfLink()

<get lastModifiedTime()>: function lastModifiedTime()

<set lastModifiedTime()>: function lastModifiedTime()

<get lastModifiedTimeOfLink()>: function lastModifiedTimeOfLink()

<set lastModifiedTimeOfLink()>: function lastModifiedTimeOfLink()

<get leafName()>: function leafName()

<set leafName()>: function leafName()

<get parent()>: function parent()

<get path()>: function path()

<get permissions()>: function permissions()

<set permissions()>: function permissions()

<get permissionsOfLink()>: function permissionsOfLink()

<set permissionsOfLink()>: function permissionsOfLink()

<get persistentDescriptor()>: function persistentDescriptor()

<set persistentDescriptor()>: function persistentDescriptor()

<get target()>: function target()

<prototype>: Object { … }

--

There's still no that debug file, but I think, it's because the command is executed successfully.

I'm glad to hear it's working. Ideally I would like to fix this so that the user doesn't have to just magically know to reset the permissions on that directory. But, unfortunately, the fix is a bit more complicated than it might seem.

If we just ignore failures to create that directory, it might be created successfully later. And then it would be created with the wrong permissions, by Firefox. And update would fail and it would sort of be Firefox's fault. So I'm not keen on that.

We could report the error to the user and get them to download and run the installer. Which would update Firefox, but it wouldn't fix the issue. We could have the installer fix the issue but, as I've discovered in the past, it is shockingly difficult to fix arbitrarily broken permissions on a public directory. I actually wasn't aware of the /reset switch to icacls. Depending on exactly how that works, it's possible that in certain situations that could help us. But I'm suspicious that, depending on exactly how the permissions are messed up, it might not work without elevated permissions. Which probably puts us right back in the problem of it being difficult to fix broken permissions on a public directory. We could do a best-effort attempt to try to fix them as the current user. Which would fix some situations, so it would be an improvement. Even though there are presumably other situations that it couldn't fix.

I'll have to think about this.

Here're the permissions to ProgramData folder and that Mozilla folder after resetting them:

C:>icacls "C:\ProgramData"
C:\ProgramData BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

Successfully processed 1 files; Failed processing 0 files

C:>icacls "C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38"
C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38 BUILTIN\Users:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

C:>

Yes, it indeed doesn't sound an easy job to build a fix, that would work for all. And in this case, the problem is actually not in Firefox (eventhough it seems it's in Firefox) but in those odd permissions. Probably if Firefox could give some hint to user, it would be an improvement. For example, if it could get that directory, it would tell that it won't have access to that directory or something.

But thank you very much for your help so far!

Br,
Janne

Hmm. Looking at the default permissions of the C: drive (on my computer, at least), I can see how it decided on those permissions. But those are not actually the default permissions that Windows gives that directory. That's unfortunate. We could have Firefox set the permissions to what is usually the defaults. But it makes me nervous that we would be assuming that the default ProgramData permissions are exactly the same across all systems. I don't know if that is a good idea.

ISTM there are at least 3 things we could do here, one of which is currently being discussed and is clearly non-trivial:

  1. try to fix the permissions on this directory we want to use (which sounds difficult and might not always work)
  2. make the prefs/settings page not fall over completely when things are broken like this (esp. as it sounds we might not be able to fix them even if we do try)
  3. display a warning in/near updater prefs UI, the about: dialog, and/or on the hamburger menu or similar when users are in this situation, that points to a SUMO page explaining how to fix it themselves.

I wouldn't want to do all 3 in this same bug, but equally I would like to make sure that we fix at least (1) and, if (0) is hard, fix (2) as well. Kirk, does that make sense or am I missing something?

Status: NEW → RESOLVED
Closed: 4 months ago
Flags: needinfo?(bytesized)
Resolution: --- → FIXED

wth, bugzilla.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW

(In reply to :Gijs (he/him) from comment #58)

ISTM there are at least 3 things we could do here, one of which is currently being discussed and is clearly non-trivial:

  1. try to fix the permissions on this directory we want to use (which sounds difficult and might not always work)
  2. make the prefs/settings page not fall over completely when things are broken like this (esp. as it sounds we might not be able to fix them even if we do try)
  3. display a warning in/near updater prefs UI, the about: dialog, and/or on the hamburger menu or similar when users are in this situation, that points to a SUMO page explaining how to fix it themselves.

I definitely agree that we need to do something about point (1). But, getting into point (2) a bit, I'm mostly just not sure exactly what should happen in this case. I'm not real keen on just saying that Firefox is up to date when this fails. It seems like a similar but even worse version of Bug 1643309 to do this. But I'm not sure if we need to talk to UX about what should happen? And do we only want this to happen in the update UI? What if we encounter this problem during background update?

To make things even more confusing (and part of what made this hard to debug), it's currently not easy to identify this particular error. So if we wanted to direct users to a SUMO article on how to fix this in particular, we would probably need some way of identifying that this is indeed the problem. Which would probably require some sort of unique error code being returned here, then that would need to be translated to an identifiable nsresult here, and that would need to be propagated rather than dropped here.

In short, I'm not sure whether I'm happy about fixing (1) without doing something about (2). But (2) sounds a bit more complicated than I'd like, and I'm not sure that we can address it particularly quickly.

Flags: needinfo?(bytesized)

One question which I'm wondering: Why this problem with ProgramData folder permissions started in version 97.0 (and exists also in newer releases)? In same machine, with same ProgramData permissions all version till 96.0.3 worked just fine. And also the newest ESR version.

And as I wrote in original post, this problem occurred in my both computers which are running Windows 10. So far I have only changed permissions in my laptop and it fixed the issue. I'll do the same fx as soon as possible also in by workstation to see, will it fix the issue also there. But eventhough the permission seemed to be odd, it didn't cause any issue earlier before version 97.0 and neither in ESR version.

Br,
Janne

Update. I now tested that fix also in my W10 workstation and it seemed to work. The original situation with permissions was identical with permissions in laptop. Only these existed:

C:\Users\habbe>icacls C:\ProgramData
C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)

I had Firefox ESR (latest version) and it worked fine. Also that about:preferences#general page. In ProgramData folder there was a directory called "Mozilla".

I then uninstalled that ESR version and installed the latest normal version. Problem with about:pereferences#general occurred again. I then close the Firefox and gave this command:

icacls "c:\ProgramData" /reset /T /C

I then opened Firefox and monitored the content of ProgramData folder. As soon as I had opened Firefox, it created a new path called "Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38" and everything worked again fine.

So that fix seems to work, but how ESR version is able to create that "Mozilla" directory while this normal version is not able to do that "Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38" directory?

Br,
Janne

I believe that what happened here is this: Firefox was installed and it created its update directory at C:\ProgramData\Mozilla with the correct permissions. At some point after this something came along and changed the permissions on C:\ProgramData. But this didn't affect Firefox because when it would go to create C:\ProgramData\Mozilla, it would find that it already existed and move on. Then, in version 97, the update directory was changed from C:\ProgramData\Mozilla to C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38. Once again, Firefox would attempt to create its update directory. Instead of discovering that it already exists, Firefox would actually need to create it now. But it would be unable to because the permissions on C:\ProgramData did not allow it to. This causes errors to be thrown that ultimately resulted in the symptoms that you saw.

That sounds reasonable. However one think is not correct. Even with those odd permissions when I installed Firefox 96.0.3 or the latest ESR version, Mozilla directory had successfully created in ProgramData. I'm sure about that because I manually removed everything which was related to earlier versions. Also that Mozilla directory in ProgramData.

Just a wild guess, but could it be, that creating Mozilla directory is somehow different than creating that Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38 directory?

Br,
Janne

It could be because we used to have a way of elevating to fix the permissions that directory. I wouldn't have thought it would activate in this case, but maybe. But we can't do that anymore. But other than that, we aren't creating the directory any differently.

Whiteboard: [fidedi-ope]
Assignee: nobody → bytesized
Blocks: 1787309
See Also: → 1787310

I've been given permission to just go ahead and add an error string to the Update UI, so I will be posting a patch here that catches this error when it happens. For now, at least, it will show a pretty generic error message that indicates an internal error and points the user to the manual update link.

I hope to later expand this to additionally showing a SUMO link explaining how to fix this issue. This will be done in Bug 1787309.

This patch adds a state to AppUpdater to represent when an internal error has occurred. It also adds the appropriate code to the Update UI to be able to handle this state, along with a panel in each UI and a string that can go in the panels to convey to the user that update has failed.

Ideally, it would be good if this message also directed the user to a SUMO article. See Bug 1787309 for details on this. But at the moment, I would prefer to address Bug 1756450 quickly rather than wait for that to be ready.

Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6667c2417ad4
Add AppUpdater.STATUS.INTERNAL_ERROR r=bhearsum,fluent-reviewers,preferences-reviewers,desktop-theme-reviewers,flod
https://hg.mozilla.org/integration/autoland/rev/7b450e36ac2c
Handle AppUpdater exceptions via new INTERNAL_ERROR state r=bhearsum
https://hg.mozilla.org/integration/autoland/rev/e630ef72be8d
Add test for updater's new internalError state r=bhearsum
Status: NEW → RESOLVED
Closed: 4 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch
Regressions: 1792337
Regressions: 1792862
You need to log in before you can comment on or make changes to this bug.