Addon menu not showing when addon icon on toolbar
Categories
(WebExtensions :: Frontend, defect, P3)
Tracking
(Not tracked)
People
(Reporter: elitarform, Unassigned)
References
Details
Attachments
(1 file)
26.72 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- Install an addon
- In "Customize Firefox" menu drag an addon icon to the toolbar
- Exit "Customize Firefox" menu
- Click on an addon icon
Actual results:
An empty blob appeared but the addon option menu is missing.
Expected results:
Addon option menu should have appeared inside the blob.
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
I should note that this bug occurred on FF 67 as well.
Comment 2•6 years ago
|
||
Hello,
I’ve attempted to reproduce the issue on the latest Nightly (70.0a1 / 20190722214346), Beta (69.0b6 / 20190718172058) and Release (68.0.1 / 20190717172542) under Windows 10 Pro 64-bit, macOS High Sierra 10.13.6 and macOS Mojave 10.14.5, with no success.
I’ve performed the test in the following manner:
-
Installed ‘To Google Translate’ extension (as this appears to be the one in the attached screenshots)
Note: The extension icon is automatically added to the toolbar and when clicked on the option menu is properly displayed. -
Accessed the ‘Customize Firefox’ page and moved the icon of the installed extension to a different position on the toolbar
Note: After closing the customization page and clicking the icon, the option menu is properly displayed -
Removed the icon from the toolbar, accessed the ‘Customize Firefox’ page and added the icon back to the toolbar
Note: After closing the customization page and clicking the icon, the option menu is properly displayed
Tried these scenarios in already opened tabs and in new tabs as well, with no success in reproducing the issue.
Can you please retest this using latest FX Release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.
Comment 3•6 years ago
|
||
(In reply to elitarform from comment #1)
I should note that this bug occurred on FF 67 as well.
Possibly a duplicate of bug 1547348 then.
(In reply to Alex Cornestean from comment #2)
no success in reproducing the issue.
I was able to reproduce this in bug 1565928 but it's not clear what triggers it. It may only happen after using the browser (and the add-on menu) for several hours. If I manage to hit this again, I'll try to see if there's anything useful in the Browser Console.
maybe even safe mode (https://goo.gl/AR5o9d)
This doesn't make sense. You can't test for extension-related problems when they're all disabled by safe mode.
![]() |
||
Updated•6 years ago
|
Comment 4•6 years ago
|
||
(In reply to Gingerbread Man from comment #3)
If I manage to hit this again, I'll try to see if there's anything useful in the Browser Console.
Clearing the console and reproducing the issue doesn't trigger any messages. This error preceding the issue may be relevant:
TypeError: can't access dead object UAWidgetsChild.jsm:93:9
Every time the popup opens with no content, clicking it again shows the content. Then upon the third click, it's blank again, and so on.
Comment 5•6 years ago
|
||
I have the same problem on macOS Catalina beta with firefox developer edition 69.0b8. It seems it is working on fresh installed nightly. I will try to clean up and reinstall developer edition to see is it working.
Comment 6•6 years ago
|
||
I have removed everything related to firefox and it's started to work as expected.
Comment 7•6 years ago
|
||
I also had identical problem on Windows10, using 68.01. I managed to downgrade using installation package but it automatically updated again to 68.01 in background. New instalallation forced me to create new profile, which I did but manually switched back to old one.
So far FF reports it's again on 68.01 and addons menus are working, only bug is now I have english language set.
I can reproduce on MacOS 10.14.6 (18G84), with current nightly (70.0a1 (2019-08-07) (64-bit)). I have the History Autodelete extension installed. When I open the AMO site, the relevant error I see in the console is:
Security Policy: The page’s settings blocked the loading of a resource at inline (“style-src”).
It's repeated 70 times, all related to the history-autodelete extension.
Comment 9•5 years ago
|
||
I'm on macOS Mojave 10.14.6 and I can reproduce this bug on both Beta 70 and Nightly 71 when i enable "apz.allow_zoming" in about:config
Comment 10•5 years ago
|
||
Hello,
Based on the information provided in Comment 9, I have managed to consistently reproduce the issue on the latest Nightly (71.0a1/20190915214245), Beta (70.0b6/20190912160217) and Release (69.0/20190827005903) versions, under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.
However, @Gingerbread Man I would require clarification whether the effects of this pref are indeed related to the issue the reporter originally accused, since you seem to have more insight into the problem.
@elitarform. Could you please check in about:config whether the pref apz.allow_zoming
is accidentally set to true? Detailed steps on how to access the configuration editor of Firefox are listed here: https://support.mozilla.org/ro/kb/about-config-editor-firefox .
Updated•5 years ago
|
Updated•5 years ago
|
Comment 11•5 years ago
|
||
I never touched the apz.allow_zooming preference; it's at its default value of false.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Just wanted to comment as I posted bug 1592522, reading on here looks like apz.allow.zooming is the culprit. If I have it set to true then I get the blank blob on the addon menu, if I set it to false then it works normally. This is an issue because I use Firefox on my Surface Pro so I need the touch zooming feature, that's really the only reason I decided to go back to Firefox over other browsers.
Comment 14•5 years ago
|
||
(In reply to Alex Cornestean from comment #10)
Hello,
Based on the information provided in Comment 9, I have managed to consistently reproduce the issue on the latest Nightly (71.0a1/20190915214245), Beta (70.0b6/20190912160217) and Release (69.0/20190827005903) versions, under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.
However, @Gingerbread Man I would require clarification whether the effects of this pref are indeed related to the issue the reporter originally accused, since you seem to have more insight into the problem.
@elitarform. Could you please check in about:config whether the pref
apz.allow_zoming
is accidentally set to true? Detailed steps on how to access the configuration editor of Firefox are listed here: https://support.mozilla.org/ro/kb/about-config-editor-firefox .
This happens to me, when apz.allow.zooming is true then this bug occurs, but if it's false then the add on menu functions normally.
Comment 15•5 years ago
|
||
(In reply to spinedoc777 from comment #13)
looks like apz.allow.zooming is the culprit.
As I said at comment 11, I've always had that preference at its default value of false and I still ran into this bug sporadically. So it can't be the root cause, though I can confirm it does make the issue reliably reproducible, as multiple users have mentioned.
Comment 16•5 years ago
|
||
It has been solved on Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1560770
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Description
•