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

Steps to reproduce:

Settings...

• Privacy and Security...
• History "Firefox will" -> Changed to "Never remember history"
• Firefox asks for restart

Actual results:

All add-in icons are removed from the toolbar

Expected results:

No visual changes should have occured

The Bugbug bot thinks this bug should belong to the 'Firefox::Settings UI' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Reproducible on MacOS 11 and Windows 10 using Firefox 106 and Firefox Nightly 108.0a1.

What I would like to add here is that not all add-on icons get removed when "Never remember history" is set, it seems to be quite random.
On Release 106 out of the 7 add-ons I've installed, only 4 icons were removed, on Nightly 108 using the same 7 add-ons, all of the icons got removed.

Thank you for reporting!

I think this is in some ways a webextensions issue, to do with whether the extension browser action buttons get created in permanent private mode (which is what "never remember history" is). Presumably this has something to do with whether the extensions in question have permission to work in private browsing mode. Maybe permanent private mode shouldn't be treated the same way for extension buttons? That would need some work in the toolbars/CustomizableUI code, that wouldn't be anywhere near sufficient if the add-on still didn't do anything, so over to webextensions for further triage.

(In reply to :Gijs (he/him) from comment #3)

I think this is in some ways a webextensions issue, to do with whether the extension browser action buttons get created in permanent private mode (which is what "never remember history" is). Presumably this has something to do with whether the extensions in question have permission to work in private browsing mode. Maybe permanent private mode shouldn't be treated the same way for extension buttons? That would need some work in the toolbars/CustomizableUI code, that wouldn't be anywhere near sufficient if the add-on still didn't do anything, so over to webextensions for further triage.

yep, this issue definitely falls into the Webextensions bugzilla component, and it looks a duplicate of Bug 1574813 (and Bug 1717115) which has been closed as a duplicate of Bug 1585431, but I think we should have instead marked it as blocked on Bug 1585431 to increase the chances that the existing bug report about this (currently expected) behavior would be easy enough to find (so that it wouldn't be reported again as a separate issue) because Bug 1585431 is tracking work to make the user aware of what to expect but it may not be easy for a user reporting the current behavior as an issue to see how that bug is correlated with the issue they are actually experiencing.

For this newly filed bug I'm going to link the Bug 1574813 (and Bug 1717115) as a see also and add Bug 1585431 as a blockers for this one, hopefully that would make it quicker (for both user reporting the issue and ourselves) to determine that it is a known issue.