User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170824053622 Steps to reproduce: Installing add-ons since approx. FF53 has produced uneven loading of add-ons at startup. I use a set of security- and privacy-related Android add-ons on my FF57 Nightly. The issue relates to all versions that I have used on the phone - standard, beta, Nightly. My Xperia Z Ultra phablet has 1.5gb of memory, which should be more than enough for ordinary add-on usage, and I have allocated as much as I can in the settings with browser.cache.memory.capacity. Unfortunately, I believe that due to the way the add-ons are not being treated as essential for Firefox starting up and loading, Android KitKat 4.4.4, which has poor memory management is contributing somewhat to Firefox dropping them at start-up. Actual results: Add-ons, whether they are old or new, sometimes fail to load properly during Firefox startup, either all at once or starting with the most memory-intensive one. Sometimes one or two add-ons fail. Sometimes they are operational, but not visible in the main menu where add-on settings are housed. Often (what I assume to be) the most memory-intensive add-on will be the first to go, namely, uBlock Origin. But also Decentraleyes, HTTPS Everywhere, NoScript etc. sometimes fail to load, sometimes all of them fail to start up. Finally, almost always when I rotate the orientation of the phone while Firefox is open, Firefox will "restart" and drop all of the loaded add-ons from memory. This is a terrible thing indeed. Expected results: Add-ons should always load, and be kept in memory no matter what, due to security and privacy issues (uBlock Origin, Decentraleyes, HTTPS Everywhere, NoScript etc.).

Today, the same happened on my Samsung Galaxy Tab S 10.5 57.0a1, 2017-09-11. Add-ons other than Phony failed to populate in the menu. Even force closing and restarting the browser didn't help.

We currently don't block start up waiting for add-ons to load. There's a discussion of this in bug 1378459.

This doesn't quite sound like bug 1378459 - that seems to be about add-ons not being guaranteed to be fully operational immediately after startup and therefore affecting e.g. a pageload occurring while the browser is started. This on the other hand is about add-ons occasionally failing to load (or at least add their menu items) at all.

(In reply to Jan Henning [:JanH] from comment #3) > This on the other hand is about add-ons occasionally failing to load (or at > least add their menu items) at all. The original bug report says: > Sometimes one or two add-ons fail. Sometimes they are operational, but not > visible in the main menu where add-on settings are housed. This is not really much to work with, could we get some more detail? Lets start with specific extensions and versions that you're using? Then, what do you mean by "the main menu where add-on settings are housed"? Do you mean that entries that should appear in the top-level application menu are not showing up? Or are you describing something in about:addons? If you can get logs from one of these events (ie, with "adb logcat") that would help a lot. > Finally, almost always when I rotate the orientation of the phone while > Firefox is open, Firefox will "restart" and drop all of the loaded add-ons > from memory. This is a terrible thing indeed. This is a distinct issue, can you please file a separate bug for it with as much detail about the circumstances in which it happens as possible?

To get us started, I will provide you with a list of the add-ons being used. That said, I will re-preface this list by adding that asking for such a list rests upon the assumption that this issue is specific to certain add-ons or versions. I do not believe this to be the case. In my usage experience of Firefox on KitKat, throughout the more recent history of the application on the platform (let's say, from Firefox versions 48 to 57), each and every add-on, every version of those add-ons that I've had on every version of Firefox, to date, has failed to load at boot at some point. Usually, again, the issue is that none of them load at all. This alone leads me to believe it is a structural issue, either with memory management on the Android platform, or in Firefox's way of not treating add-on boot-up loading as essential (as per in the other referenced bug). Here is my current primary list: Decentraleyes 2.0.0beta2 https://addons.mozilla.org/en-GB/firefox/addon/decentraleyes/versions/beta?page=1#version-2.0.0beta2 HTTPS Everywhere 2017.9.12.1337-eff.xpi (Latest test WebExtensions version) https://www.eff.org/files/https-everywhere-test/index.html Video Background Play Fix 1.2.1 https://addons.mozilla.org/en-GB/firefox/addon/video-background-play-fix/ Chrome UA on Google for Firefox Android 1.2 https://addons.mozilla.org/en-GB/firefox/addon/chrome-ua-on-google-android/ uBlock Origin 1.14.8 https://addons.mozilla.org/en-GB/android/addon/ublock-origin/ The following were used up until they were disabled a few days ago in 57: usi (User|Unified Script Injector) 0.4.16 https://addons.mozilla.org/en-GB/firefox/addon/userunified-script-injector/ Phony 3.6.2 https://addons.mozilla.org/en-GB/android/addon/phony/ Desktop Mode Add-on 1.5.1 https://addons.mozilla.org/en-GB/android/addon/desktop-mode-add-on/ I hope your question regarding the add-on options menu elements is not facetious. Having a submenu in the main menu, strictly for housing add-on option menu elements, sounds like the pertinent implementation to solve such lack of clarity! To be absolutely clear, I refer to as "main menu" the primary triple-dot dropdown that houses access to every feature of the browser (Bookmarks, History, Tools, Settings, etc.), including per-addon options elements at the very bottom of it. Currently they load at the bottom of the menu, which 1) allows users to know an add-on is properly installed, 2) properly working, and 3) allows access to the add-ons' features. For this bug, the relevance of the various add-on menu elements is in that just looking at the menu will almost always tell whether add-ons loaded properly or not; I've seen other users report that the add-on functionality is sometimes there despite no menu element loading. This is almost never the case for me. Even if an add-on fails to load, it is accessible at about:addons, and their options can be manipulated from there. This doesn't help with making the add-ons load, however. A starting point of inquiry may be that on the Samsung tablet (Marshmallow), it is necessary to force close the application for Firefox to try to reload the add-ons. Merely closing the app in the Android application menu is not enough. i.e. if the application remains in memory, it will not attempt to re-load the add-ons. Conversely, however, on my Z Ultra (KitKat), swiping the application away in the Android application switcher is enough to re-activate the loading procedure. I will see if I can get a reasonable logcat log from the phone. I already tested the output and there's a lot of crud produced by the rest of my customizations on the phone, so it may be difficult to read the output. Can I limit the output in some way (i.e. with a command line option like "adb logcat -e") that you would prefer, that would still contain the necessary information, to make it more readable for you? Furthermore, do you need logs of the add-ons both loading properly and not loading, or is it enough to capture a failure state?

Wesly would someone on the Fennec team be able to help us diagnose this for 57?

Sorry Andy, I doubt if we are able to check this recently as we have less than 2 people in 58 nightly cycle and we have Photon (57 Beta) and PWA in hands. I'll put it into our Sprint list to see if we can get them into the coming Sprints.

Also ni Joe to make necessary prioritization.

Somebody in the other bug mentioned bug 832990. From the description here it's not entirely clear whether this bug is a straight duplicate or just having very similar symptoms, but at least with bug 832990 the root cause is already known, so a fix hopefully shouldn't be too difficult too produce (famous last words).

My don't keep activities is off on all my devices so I don't think it's that.

Android may drop activities any time while they're backgrounded if the device is running low on memory or the OS otherwise just feels like it. The option is only there to force this to happen *every* time you background the app to make testing and weeding out of bugs easier, but you can still run into this problem even if you don't mess around with that option.

I get what you're saying, but bug 832990 specifically states that preference being on as a factor of the issue. I believe these to be two different bugs all be it with similar issues. I believe that even if these were the same bug, we're conflating symptoms with causes. The crux of the issue here is that there's no code to ensure that a/ extensions are initialised properly and b/ that extension buttons (menu items) can be added to the UI after the UI has rendered.

I suspect this might be a duplicate, but I'm not entirely confident. Once that bug is fixed, we'll see if this still happens through some other cause...

Happens every day on my Axon7, Snapdragon 820 processor, 4GB memory. NoScript, uBlock, Decentraleyes. I've had other extensions as well but remove them thinking it might help. The only workaround is to disable and reenable each extension to get them to load and then refresh the web page for them to load. Lastpass and others do it too. I don't think it has anything to do with what sort of extension it is nor memory usage. It just seems to happen whenever.

Forgot to add I'm on Android 7.1.2