Context menu for add-ons missing after restarting Firefox
Categories
(WebExtensions :: General, defect)
Tracking
(firefox128 affected, firefox129 affected, firefox130 affected)
People
(Reporter: tom_xyz, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
- Updated from Firefox 128.0.2 to 128.0.3.
- Restarted Firefox
Actual results:
My add-on's context menu is gone after restarting. It looks like a regression bug with 128.0.3 because it was showing up fine in 128.0.2.
Expected results:
The add-on's context menu should be visible.
Comment 1•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•10 months ago
|
||
Hello,
I could not reproduce the issue on Firefox 128.0.2 updated to the latest 128.0.3 (128.0.3/20240725162350) under Windows 10 x64.
I installed several extensions that have context menu options (ClearURLs, uBlock Origin and Read Aloud: A Text to Speech Voice Reader) and accessed https://en.wikipedia.org/wiki/Main_Page. There I checked that the context menu options are displayed and work, which they did.
I then updated the browser to the latest 128.0.3 version and checked the context menu options on the mentioned page once again. The options were still displayed and worked.
Finally, I restarted the browser and re-checked that the context menu options were still displayed and worked, which once again, they did.
Is there a particular extension you used that exhibited this behavior so I can check that one out, as well?
Updated•10 months ago
|
Alex, thanks for testing. There might be something wrong with my installation of Firefox since the last update to v128.0.3 because I just installed uBlock Origin and, like other extensions, I do not see a context menu. This issue was brought to my extension by users of my own extension, so I know I'm not alone in having this issue.
https://i.imgur.com/c2dEdXp.png
The extension I'm testing with is Lightning Autofill:
https://addons.mozilla.org/firefox/addon/lightning-autofill/
After installing, you should see a Lightning Autofill context menu. This extension uses the same code base as the Chrome/Edge version, which is not exhibiting this issue (i.e., after installing Chrome/Edge version, you see the context menu). You can try the other versions here:
https://chrome.google.com/webstore/detail/autofill/nlmmgnhgdeffjkdckmikfpnddkbbfkkk
https://microsoftedge.microsoft.com/addons/detail/lkfeipbjpgibcbhhciamknhfdpjemfke
Again, I only started seeing the context menu disappear after Firefox updated to v128.0.3 and restarted. I have heard from one user that after they downgraded to v128.0.2 (portable), the context menu is still missing. Let me know if there's any other info I can give you to try and get to the bottom of this.
Comment 4•10 months ago
|
||
Thank you Tom for the additional info !
I rechecked the issue, this time with both uBlock Origin and Lightning Autofill installed on 128.0.2 (initially both context menu options were displayed) and then updated to 128.0.3.
Initially, immediately after the browser restarts post update, both context menu options were still displayed. However, after one manual browser restart, the Lightning Autofill context menu was indeed gone, while the context menu option for uBlock Origin remained.
I tried, disabling/enabling Lightning Autofill and even multiple other browser restarts and the context menu for it did not re-appear.
Again, I do want to stress the fact that the context menu for uBlock Origin is still present even after disabling/enabling the add-on and after several browser restarts.
On Nightly and Beta, the issue occurred the same way, only with Lightning Autofill (and not uBlock Origin), but this time immediately after the browser restarts as part of the update process instead of after one manual restart after the browser was updated.
Tested on:
- Firefox 128.0.2 updated to the latest 128.0.3 (128.0.3/20240725162350) under Windows 10 x64.
- Nightly 130.0a1/20240728214119 updated to 130.0a1/20240729204357 under Windows 10 x64.
- Beta 129.0b9/20240726091552 updated to 129.0/20240729133145 under Windows 10 x64.
At this point, I’m not entirely sure this is an issue with Firefox, but with the extension itself, since uBlock Origin does not appear to be affected.
Nonetheless I’ll set the report to new and mark all tested Firefox versions as affected, for the moment.
Thanks for additional testing. I will do some more troubleshooting as well, but in the meantime...
-
Do you know why I don't see uBlock Origin context menu after installing it?
-
How can I test a possible fix when the local extension (debugging) is removed upon restarting?
-
Is there a known discrepancy between the way Firefox and Chrome implements the ContextMenu API? I'm asking because this issue only occurs in Firefox.
It's possible that the developer of uBlock Origin added their own fix to work around this issue, so we can't rule out that it's not a bug in Firefox just because it works in uBlock Origin. I will try to create a minimal extension using ContextMenu API to see if I can reproduce it.
Comment 7•10 months ago
|
||
(In reply to Alex Cornestean from comment #4)
Thank you Tom for the additional info !
I rechecked the issue, this time with both uBlock Origin and Lightning Autofill installed on 128.0.2 (initially both context menu options were displayed) and then updated to 128.0.3.
Initially, immediately after the browser restarts post update, both context menu options were still displayed. However, after one manual browser restart, the Lightning Autofill context menu was indeed gone, while the context menu option for uBlock Origin remained.
Hey Alex, given that you managed to reproduce the issue at least on the Lighting Autofill extension, if you can reproduce it consistently enough would you mind to look if there is any useful / suspicious errors or warnings logged in the browser console when you hit it right after the additional browser restart? (make sure to enable the multi process mode on the browser console to also be able to see errors or warnings only logged in the child processes)
Comment 8•10 months ago
|
||
(In reply to Tom Doan from comment #5)
Thanks for additional testing. I will do some more troubleshooting as well, but in the meantime...
- Do you know why I don't see uBlock Origin context menu after installing it?
Hard to say with the details currently available, and there may be differences between your ublock origin installation and Alex's one (e.g. they may be configured differently and the configurations/stored data of the extensions may have a role in how the issue is hit).
is there any error/warning logged in the browser console right after the browser / extension is started or right after opening the context menu that feels like they may be related to the issue being hit?
That may help us to get a better picture of how the issue is being hit in your Firefox instance (and gather enough details to get to steps to reproduce the issue consistently and investigate it further).
- How can I test a possible fix when the local extension (debugging) is removed upon restarting?
That's definitely tricky, there would be at least a couple of options:
-
use unbranded builds that matches the release versions that are hitting the issue, on unbranded build the signature checks can be manually disabled from about:config (xpinstall.signatures.required set to false) as in nightly builds
-
sign an unlisted version (e.g. with additional debugging log added temporarily) on AMO and use that unlisted signed xpi to investigate further
- Is there a known discrepancy between the way Firefox and Chrome implements the ContextMenu API? I'm asking because this issue only occurs in Firefox.
Edge implementation is exactly the same as Chrome, given that Edge is nowdays built on top of Chromium source base, whereas both Firefox and Safari have their own independent implementations of the WebExtensions APIs, and the internals of Firefox and Safari are completely independent from Chrome internals (while Edge largely shares the same underlying implementation) and so subtle differences are not unlikely and bugs in one are not always implicitly hit across different implementations.
Comment 9•10 months ago
|
||
The only thing I see in the browser console that might be somewhat relevant is this warning
initNSMouseEvent() is deprecated. Use the MouseEvent() constructor instead. nsContextMenu.js:87:12
. However, this shows up even when only uBlock Origin is installed. And as far as I can tell, this is logged when I right click for the first time after installing the add-on, when I right click post browser update or when I right click after I restart the browser.
There’s also these two warnings
browser.ui.customized_widgets - The key length must be limited to 72 characters.
Request for font "Gill Sans" blocked at visibility level 3 (requires 4) quickstart
when first installing the Lightning Autofill extension and the quick start guide tab auto launches. But this does not appear relevant in any case.
Other than these, there’s nothing else that stands out. No errors or anything
Reporter | ||
Comment 10•10 months ago
|
||
Hi all, I have identified the root cause: the extension was MV2 with a persistent background page. According to MDN:
persistent background pages: in Firefox, menu items from persistent background pages are never persisted. Call
menus.create
unconditionally from the top level to register the menu items.
The problem was, in the extension menus.create
was called from the runtime.onInstalled
handler. The issue was resolved by making the background page non-persistent:
"background": {
"persistent": true,
"scripts": ["background.js"]
},
Thank you all for looking into this, and apologies for the false positive.
Reporter | ||
Comment 11•10 months ago
|
||
Correction for previous message: persistent
should be FALSE.
"background": {
"persistent": false,
"scripts": ["background.js"]
},
Description
•