some users report empty content for about:preferences#general (exceptions from unavailable services from app updater code)
Categories
(Toolkit :: Application Update, defect, P3)
Tracking
()
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 |
config-prefs.jpg
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.
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
[Tracking Requested - why for this release]:
Broken primary UI (prefs/settings)
| Comment hidden (obsolete) |
|
|
||
Comment 3•2 years ago
|
||
This is very confusing. Nothing in the ESR pushlog looks at all related.
Looks like ryan says the pushlog should be:
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?
|
|
Reporter | |
Comment 4•2 years ago
|
||
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).
|
|
||
Comment 5•2 years ago
|
||
(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 ?
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 6•2 years ago
|
||
|
|
Reporter | |
Comment 7•2 years ago
|
||
I asked for the problematic value of general.config.obscure_value, will provide the answer ASAP.
|
|
||
Updated•2 years ago
|
|
|
||
Comment 8•2 years ago
|
||
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.
|
|
||
Comment 9•2 years ago
|
||
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?
|
|
Reporter | |
Comment 10•2 years ago
•
|
||
(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.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 11•2 years ago
|
||
(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
|
||
Comment 12•2 years ago
|
||
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).
|
|
||
Comment 13•2 years ago
•
|
||
(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.
|
||
Comment 14•2 years ago
|
||
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.
|
|
||
Comment 15•2 years ago
|
||
(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.
|
|
||
Comment 16•2 years ago
|
||
(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.
|
Assignee | |
Comment 17•2 years ago
|
||
(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.
|
|
Reporter | |
Comment 18•2 years ago
|
||
(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.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 19•2 years ago
|
||
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.
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 20•2 years ago
|
||
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
|
|
Assignee | |
Comment 21•2 years ago
|
||
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.
|
|
||
Comment 22•2 years ago
|
||
Given what we know about the issue at this point, I don't think we need to track it.
|
|
Reporter | |
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Comment 23•2 years ago
|
||
:bhearsum is this still considered an S2, if so do we expect a fix in the medium term or is it an S3?
|
||
Comment 24•2 years ago
|
||
(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.)
|
||
Updated•2 years ago
|
|
||
Comment 25•2 years ago
|
||
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
|
|
||
Comment 26•2 years ago
|
||
(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!
|
|
||
Comment 27•2 years ago
|
||
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
|
|
||
Comment 28•2 years ago
|
||
|
|
||
Comment 29•2 years ago
|
||
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?
|
|
Assignee | |
Comment 30•2 years ago
|
||
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?
|
||
Comment 31•2 years ago
|
||
(In reply to Kirk Steuber (he/him) [:bytesized] from comment #30)
It looks like
about:preferencestries to load theAppUpdater, which tries to load theUpdateManager. And theUpdateManageris 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.getDiris passing inUpdRootD. So the fact that the directory service is responding withNS_ERROR_FAILUREseems 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 forUpdRootDin thensIPropertiesinterface because theUpdRootDgetter 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
UpdRootDentry 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?
|
|
||
Comment 32•2 years ago
|
||
(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
|
|
Assignee | |
Comment 33•2 years ago
|
||
(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?
- Check that
about:preferences#generalis still experiencing the same problem. - Enable running commands in the Browser Console by navigating to
about:configand settingdevtools.chrome.enabledtotrue. - Open the Browser Console, either via Control+Shift+J or Hamburger Menu->More Tools->Browser Console.
- 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.
|
|
||
Comment 34•2 years ago
|
||
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
|
|
Assignee | |
Comment 35•2 years ago
|
||
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.
- 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.
- Run the custom build and make sure that we can still reproduce the problem. That is to say, make sure that
about:preferences#generaldoesn't display correctly. - Enable running commands in the Browser Console by navigating to
about:configand settingdevtools.chrome.enabledtotrue. - Open the Browser Console, either via Control+Shift+J or Hamburger Menu->More Tools->Browser Console.
- 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.
|
|
||
Comment 36•2 years ago
|
||
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:
|
|
||
Comment 37•2 years ago
|
||
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
|
|
||
Comment 38•2 years ago
|
||
Hmm, I couldn't find that log file firefox-custom-build-log.txt in %ProgramData%.
Br,
Janne
|
|
Assignee | |
Comment 39•2 years ago
|
||
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.
|
|
||
Comment 40•2 years ago
|
||
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
|
|
Assignee | |
Comment 41•2 years ago
|
||
(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!
|
|
Assignee | |
Comment 42•2 years ago
|
||
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!
|
|
||
Comment 43•2 years ago
|
||
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
|
|
||
Comment 44•2 years ago
|
||
|
|
||
Comment 45•2 years ago
|
||
|
|
||
Comment 46•2 years ago
|
||
This is the error message expanded:
|
|
||
Comment 47•2 years ago
|
||
This is the error message expanded:
|
|
||
Comment 48•2 years ago
|
||
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 { … }
|
|
Assignee | |
Comment 49•2 years ago
|
||
(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.
|
|
Assignee | |
Comment 50•2 years ago
|
||
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.
|
|
||
Comment 51•2 years ago
|
||
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
|
|
||
Comment 52•2 years ago
|
||
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.
|
|
||
Comment 53•2 years ago
|
||
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.
|
|
Assignee | |
Comment 54•2 years ago
|
||
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.
|
|
||
Comment 55•2 years ago
|
||
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:>
|
|
||
Comment 56•2 years ago
|
||
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
|
|
Assignee | |
Comment 57•2 years ago
|
||
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.
|
|
||
Comment 58•2 years ago
|
||
ISTM there are at least 3 things we could do here, one of which is currently being discussed and is clearly non-trivial:
- try to fix the permissions on this directory we want to use (which sounds difficult and might not always work)
- 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)
- 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?
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 60•2 years ago
|
||
(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:
- try to fix the permissions on this directory we want to use (which sounds difficult and might not always work)
- 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)
- 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.
|
|
||
Comment 61•2 years ago
|
||
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
|
|
||
Comment 62•2 years ago
|
||
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
|
|
Assignee | |
Comment 63•2 years ago
|
||
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.
|
|
||
Comment 64•2 years ago
|
||
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
|
|
Assignee | |
Comment 65•2 years ago
|
||
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.
|
|
Assignee | |
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 66•2 years ago
|
||
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.
|
|
Assignee | |
Comment 67•2 years ago
|
||
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.
|
|
Assignee | |
Comment 68•2 years ago
|
||
Depends on D156998
|
|
Assignee | |
Comment 69•2 years ago
|
||
|
||
Comment 70•2 years ago
|
||
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
|
||
Comment 71•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/6667c2417ad4
https://hg.mozilla.org/mozilla-central/rev/7b450e36ac2c
https://hg.mozilla.org/mozilla-central/rev/e630ef72be8d
|
|
||
Updated•2 years ago
|
Description
•