Closed Bug 1760601 Opened 2 years ago Closed 2 years ago

Invisible Add-on Extensions in 98.0.1 (64-bit)

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Version:
Firefox 98
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: chrisdhorner, Unassigned)

Details

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

Steps to reproduce:

Received the automatic update to Firefox.
Firefox updated itself to 98.0.1 (64-bit).
Firefox asked me to update from the previous browser.
I said "No" because Firefox was already my previous browser.
Firefox updated.

Actual results:

I lost all of my many saved OneTab lists (AND AM NOT HAPPY ABOUT THIS).
Some of my previous Add-on extensions seemed to have disappeared.
But when I looked at Manage Extensions, these extensions were all there.
I discovered that if I hover the mouse over the gaps in the extensions area, that the extensions still exist in the bar but the icons are are now invisible.

Expected results:

When you ask users the question:
"Do you want to update from the previous browser",
you should explicitly state "Including importing your previous FIREFOX settings".
Firefox should not delete previous saved tabs like OneTab.
Firefox should make all previously installed Add-on extension icons visible as normal.

I have discovered that if I did the following actions, it solved the problem:

  1. Add-ons and themes.
  2. Extensions (Manage Extensions).
  3. Disable, then re-Enable each of the extensions with invisible icons.
  4. Resulted in the invisible Add-on Extension icons re-appearing in the extensions area.
  5. This allowed me to then move these now visible Add-on Extension icons around by right clicking and choosing Customize Toolbar.

So the Invisible Add-on Extensions in 98.0.1 (64-bit) bug seems to be to do with needing to refresh (Disable, then re-Enable) the Add-on Extensions during the Firefox update.

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.

Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit

Hello,

I’ve attempted to reproduce the issue you are having using Firefox 98.0 which got updated to the latest version – 98.0.2, under Windows 10 x64, however without success.

To replicate the results you’ve obtained, I’ve installed an older version of Firefox (98.0) and initially disabled automatic updates (please note that I’ve kept all other Firefox’s settings regarding browser updates at default).
I’ve then proceeded to install several add-ons which show icons on the toolbar, including uBlock Origin, Weather, OneTab, Enhancer for YouTube and Bitwarden.
I’ve also opened multiple tabs, brought them all into OneTab and named that tab group. Please note that I’ve attempted to reproduce the issue with both the created tab group locked and unlocked over several attempts.

Afterwards, I’ve re-enabled browser automatic updates and restarted the browser.

Upon restart the browser got updated to the latest version (98.0.2) without issues, all installed add-on icons were still properly visible on the toolbar and both the locked and unlocked tab groups from OneTab were still there.

Hi Alex,

The message that is mentioned in comment 0 seems to be likely this one:

that is used in the windows stub installer here:

The stub installer should be a pretty tiny executable (based on the stub installer docs it should be just ~200-300 KB).

if I recall correctly it should be the default way Firefox is installed on Windows but I wanted to double-check with you:

  • if in the test you did the stub installer was the installer being used
  • if you have ever being able to see the dialog mentioned in comment 0
  • if you got the dialog mentioned in comment 0, was it triggered while the Firefox instance was still running?

I don't know enough about the stub installer to know if there are ways to force certain behaviors, we may needinfo someone from the team that is maintaining the "Firefox :: Installer" component to get their perspective on the issue and guidance on how to recreate conditions similar to what is described in comment 0.

Flags: needinfo?(acornestean)

Hi Luca,

Since I had a hunch I will have to repeat the tests more than a few times, I used the unpacked .zip version of the browser available from the Mozilla FTP (https://archive.mozilla.org/pub/firefox/releases/). Once the browser is updated and have no more use for it in this state, and I have to repeat the test, I simply delete the folder where I unpacked the browser and start again.

So to answer your questions:

  1. I did not use the stub installer, instead I used the .zip version of the browser from the Mozilla FTP as mentioned above.
  2. I did not see the dialog mentioned in comment 0

I also lack knowledge in regards to the stub installer. So if you could needinfo the proper person/s to guide me on how to create a similar environment as used by the reporter, that would be great !

Thank you !

Flags: needinfo?(acornestean) → needinfo?(lgreco)

Hi Amir,
we'd need some help from an engineer with more direct knowledge about the stub installer, in particular to determine:

  • if the dialog mentioned in the STR from comment 0 the one that belongs to the stub installer (as it seems based on a quick look on searchfox)
  • how we may properly reproduce the conditions that are described in the STR using the stub installer

I'm also wondering if there is any existing issue filed in the "Firefox :: Installer" component that may be related to this issue.

The perspective of someone with more direct knowledge about the stub installer would be very helpful to get to an STR we could use to reproduce the issue and look more closely in what may be the actual underlying issue that triggers it.

who would be a good pick to needinfo about these details related to the stub installer?

Thanks in advance for your help.

Flags: needinfo?(lgreco) → needinfo?(ahabibi)

Please reopen if you're able to provide more info.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE

Hi Luca,
Apologies for getting back to you late on this. Looping in :bytesized: to see if he can shed some light on this.

Flags: needinfo?(ahabibi) → needinfo?(bytesized)
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INCOMPLETE → ---

(In reply to ChrisDHorner from comment #0)

"Do you want to update from the previous browser",

I have no idea what this is. If it's important that we know what this dialog is, we should probably try reaching out to the reporter to ask for a screenshot or something. I could likely figure it out from that.

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #4)

The message that is mentioned in comment 0 seems to be likely this one:

that is used in the windows stub installer here:

I think it's unlikely that it's that one. That is the message that you get if you try to cancel the stub installer by clicking the X in the corner.

Status: REOPENED → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(bytesized)

Hi Chris,
would you be able to provide a screenshot of the dialog with the message that you are mentioning in comment 0?

Flags: needinfo?(chrisdhorner)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:willdurand, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(chrisdhorner) → needinfo?(wdurand)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago → 2 years ago
Flags: needinfo?(wdurand)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.