Extension appears enabled but doesn't work until re-enabled; problem reoccurrs each time Firefox starts
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
People
(Reporter: kalthorn, Unassigned)
References
Details
(Whiteboard: [addons-jira])
Attachments
(2 files)
Enabled addon appears disabled in GUI
- Starting firefox shows the installed extension "Old Reddit Redirect" as enabled.
- I click a reddit link but am not taken to old.reddit
- Disable and re-enable the extension
- reddit links now properly redirect and open reddit pages Refresh to old.reddit
Uninstalled and reinstalling does not affect this behavior. Account Sync appears to also carry this error to new Firefox installs.
Link to the tracked issue for the extension although I agree this seems be outside of the extensions scope and is likely a bug with Firefox: https://github.com/tom-james-watson/old-reddit-redirect/issues/160
One addition bit:
On the Settings page, the extension appears enabled just like my others. However it appears disabled in the GUI when I click the puzzle piece icon.
|
||
Comment 2•1 year ago
|
||
I experience this in my firefox as well.
For what it's worth, a new firefox profile with no customization besides installing this plugin does not exhibit the same problem
Hello, thank you for the bug report!
Unfortunately I could not reproduce your issue. I can confirm that the extension indeed looks disabled as seen in your screenshot, but it is fully functional. Everytime I opened reddit, it loaded the old page format, as per the expected outcome. Would you be so kind as to answer a few questions so we can investigate this further?
- Can you please attach a copy of your about:support information?
- Does this issue happen with latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
- Does this issue happen when Firefox is in Troubleshoot Mode? Here’s a link on how to enable it: https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-troubleshoot-mode
Thank you.
|
||
Comment 4•1 year ago
|
||
Chiming in to say that I am also experiencing this bug on Firefox Developer Edition.
I was able to reproduce this on a new and empty profile.
- Install "Old Reddit Redirect" (https://addons.mozilla.org/en-US/firefox/addon/old-reddit-redirect/)
- Install "Kagi Search for FIrefox" (https://addons.mozilla.org/en-US/firefox/addon/kagi-search-for-firefox/)
- Visit reddit.com
Expected: reddit.com is redirected to old.reddit.com
Actual: Old Reddit Redirect does nothing and the regular reddit.com is loaded.
The temporary fix found is to disable Old Reddit Redirect and reenable, which fixes the problem for the current session of Firefox. This fix needs to be redone when restarting Firefox.
I'm not certain if other add-ons cause this same bug, but I tried adding "Yandex search" and "DuckDuckGo Privacy Essentials"---the bug does not appear with these add-ons installed (while Kagi Search for Firefox is disabled).
|
|
||
Comment 5•1 year ago
|
||
|
||
Comment 6•10 months ago
|
||
This appears strongly to be a bug in Firefox. I produced a set of simple test extensions which illustrate the behavior:
https://github.com/radian-software/firefox-declarativenetrequest-bugreport
There is additional information in that repository, however the short version is that if multiple extensions try to use the declarativeNetRequestWithHostAccess permission, then after restarting Firefox, only the extension whose addon ID is alphabetically first will work properly. Disabling+reenabling the affected extension(s) causes them to return to normal behavior, until a restart.
Test run on Firefox 146.0.1, Developer Edition, and I expect that this behavior will straightforwardly reproduce on y'all's end, however please let me know if not!
|
||
Comment 7•10 months ago
|
||
Hi Radon, thank you so much for the test extensions you have linked from comment 6, the notes in the repository and the test extensions included in it have been very useful to dig into the issue and pinpoint the actual underlying issue.
NOTE: as a side note, the issue is hit on browser restart and so the STR requires a Firefox build where xpinstall.signatures.required pref can be flipped to false (e.g. Nightly) and the test extensions to be installed non temporarily (e.g. from about:addons).
Based on what I have observed while reproducing the issue using the test extensions in the github repository linked in comment 6, the underlying issue is hit due to a race between RulesetsStore's _ensureCacheLoaded (spawned from #promiseStartupCacheLoaded) to be done with the startup cache data loading and the test extension without any DNR static ruleset (ext-causeconflict test extension) hitting the logic inside RulesetsStore #initExtension handling the case where no startup cache data is pending loading for a specific extension here: https://searchfox.org/firefox-main/rev/e7efe8e2d1b972ed4a073065bc99cfb08f6c31e9/toolkit/components/extensions/ExtensionDNRStore.sys.mjs#1175
That is also matching with the fact that order of the test extensions DNR startup data being loaded matters in the STR described in the github repo README.md.
When the ext-causeconflict test extension is initializing before the other test extension, RulesetsStore #initExtension is setting the empty data entry for the extension from here https://searchfox.org/firefox-main/rev/e7efe8e2d1b972ed4a073065bc99cfb08f6c31e9/toolkit/components/extensions/ExtensionDNRStore.sys.mjs#1175 and then _ensureCacheLoaded ends up logging the following error and exiting earlier here https://searchfox.org/firefox-main/rev/e7efe8e2d1b972ed4a073065bc99cfb08f6c31e9/toolkit/components/extensions/ExtensionDNRStore.sys.mjs#1227-1232:
Error: Unexpected non-empty DNRStore data. DNR startupCache data load aborted.
ExtensionDNRStore.sys.mjs:1228
_ensureCacheLoaded resource://gre/modules/ExtensionDNRStore.sys.mjs:1228
InterpretGeneratorResume self-hosted:1312
AsyncFunctionNext self-hosted:780
As an additional way to double-check that what I described above is what is triggering the issue, I applied locally the following small tweak to make sure that #initExtension awaits for #promiseStartupCacheLoaded() to be completed before setting the default empty data entry for the extension without have startup cache data to be loaded and that prevented the STR from still hitting the issue on the browser startup:
diff --git a/toolkit/components/extensions/ExtensionDNRStore.sys.mjs b/toolkit/components/extensions/ExtensionDNRStore.sys.mjs
index 7bbbf4d829f2..6de8b533660d 100644
--- a/toolkit/components/extensions/ExtensionDNRStore.sys.mjs
+++ b/toolkit/components/extensions/ExtensionDNRStore.sys.mjs
@@ -1167,6 +1167,12 @@ class RulesetsStore {
!extension.hasShutdown &&
!this._dataPromises.has(extension.uuid)
) {
+ // Make sure to wait for #promiseStartupCacheLoaded to have completed to load
+ // the startup cache before adding an entry to the _data and _dataPromises
+ // maps (otherwise #promiseStartupCacheLoaded's _ensureCacheLoaded may fail
+ // due to _data not being empty anymore by the time we have loaded the
+ // previous set of rules from the startup cache, see Bug 1995192).
+ await this.#promiseStartupCacheLoaded();
// #getDataPromise() initializes _dataPromises and _data (via #readData).
// This may be called when the StartupCache is not populated, but if they
// were, then these methods are not called. All other logic expects these
As next steps for this issue, we should write a test case to explicitly cover the scenario currently hitting an issue and attach a patch with the additional test coverage along with applying a fix similar to the diff included right above.
|
||
Updated•10 months ago
|
|
|
||
Comment 8•10 months ago
|
||
Hi Rob,
I just noticed that you have recently investigated Bug 2006233 and the underlying issue described in Bug 2006233 comment 3 is matching also the reasons behind this bug (described in comment 7), unfortunately I only found the other bug after I looked into this one (but on the bright side we have independently proven they are the same underlying issue).
Independently from how we are going to fix the underlying issue (either detect when the scenario and do not return earlier as we are doing at the moment, or explicitly await for the DNR startup cache data loading to be completed as I was proposing in comment 7 here), it seems these two are the exact same issue and so we should close one as a duplicate, let's determine which one we are going to keep to track the fix and close the other one as a duplicate.
Which one would you prefer to keep for tracking the fix?
|
||
Comment 9•10 months ago
|
||
I have already attached a patch to the other bug in the meantime, so let's mark this as a duplicate of bug 2006233. Your fresh analysis should make it easier to do a quick review :)
Description
•