User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Install the add-on TextArea Cache (among some others).

Click on the icon.

Actual results:

The resulting menu is empty.

If text has been saved in it's cache the menu will display properly. Once you clear it's cache an empty menu will appear when clicked on again.

Expected results:

Menu should have text in it.

Additional add-ons affected are Forget Me Not and Firefox Multi-Account Containers.

By setting 'browser.tabs.remote.autostart = false' the menus are populated properly.

See my other bug report Bug 1542884.

This isn't Windows only.

On Linux I installed TextArea Cache with the 12 April Nightly and the menu worked. I updated to the 13 April Nightly and the menu doesn't work.

The TextArea Cache menu now works (without an additional restart), and the contents are my previous comment.

The TA menu only displays cached text if there is text in the cache. Once all text is deleted from it's cache the menu is empty again. The two icons on the menu (upper right) can be seen if you move your pointer there. Occasionally you can see the complete menu with it's default text for a second. As I said there are other add-ons that also display empty menus. Some of them you can move your pointer around the empty menu and the menus text will appear. Poper Blocker does this. BTW. Forget Me Not add-on doesn't have a problem. I confused it with Poper Blocker.

I see this problem with the Nightly Tester Tools 4.0 extensions menu.

Sometimes it is filled in, other times empty. Dragging the mouse in the empty door hanger fills the text.

Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 on Linux Mint 19 Cinnamon.

This action can be a PITA especially if there is no way to have the menu fill which happens in some cases. Whether this bug is the same as Bug 1542884 I'll let Mozilla decide. Please fix it as soon as possible as well as the other bug. Thanks.

Almost closely unreproducible for me.
I could see 'white' or partially rendered panel rarely on Linux and it seems depend on timings for rendering the panel content. I couldn't see any broken panel on Windows.

However, same behaviour can be reproduced by holding mouse button on click.
See Bug 1512998.
It is 100% reproducible (with affected extensions) on both Windows and Linux. I'm guessing Bug 1512998 is real.

I have some more info on this problem. If I click on an icon really fast holding the mouse button down as little as possible the menu displays correctly. Clicking this way is not natural.

I don't want to seem like a troll but is there any movement on this issue?

Menus are appearing normally a lot more than they did before today's nightly. I still get an empty menu but it is less often now. I don't have to do a quick click on the icon to always get the populated menu. Things still aren't working as they should however.

Moving this to WebExtensions for triage and analysis. I understand from https://bugzilla.mozilla.org/show_bug.cgi?id=1542884#c8 that disabling the browser.tabs.remote.autostart pref makes the problem go away, but I don't think there is likely to be any correlation with Workers. Setting that pref to false disables e10s (multiprocess operation), which has all kinds of extensive behavior changes throughout the browser. (Changes to multi-process Blobs and Blob URL propagation could be involved if it's not directly related to the WebExtensions menu API.)

I would really like to see some progress on this issue. If there is anything needed from me please let me know.

Possible duplicate of bug 1426405?

Eh, disregard that, its about toplevel popup windows, not about browser action popups

It seems to has triggered by bug 1357487. (it's a trigger, not the cause)
Try extensions.webextensions.remote=false instead of browser.tabs.remote.autostart=false if necessary. (restart required)
Possibly another trigger is Bug 1346607.
See also Bug 1190679.

This seems to be the same issue of Bug 1416505 (Bug 1416505 comment 8 and 1416505 comment 13 provides some additional info related to this issue from past investigations).

As I just mentioned in Bug 1416505 comment 27, it seems that the rendering issue may have become easier to trigger with the changes introduced in Bug 1446027 (as a side-effect of changing the timing of the swapping between the invisible XUL browser used to preload the page and the XUL browser actually visible in the opening popup).

Bug 1547277 might have fixed this, someone should retest in a build with that fixed.

The priority flag is not set for this bug.
:ddurst, could you have a look please?

For more information, please visit auto_nag documentation.

Assuming you can reproduce this, can you re-test with an updated 68?

Problem as been fixed in the past week or so on Nightly. Sorry I didn't update this sooner as I was on Holiday.