Australis add-on icons removed in Customize reappear in toolbar with new window

RESOLVED DUPLICATE of bug 854226

Status

()

Firefox
Toolbars and Customization
RESOLVED DUPLICATE of bug 854226
4 years ago
4 years ago

People

(Reporter: nick, Unassigned)

Tracking

28 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131120062258

Steps to reproduce:

Customize the toolbar. Remove icons for add-ons from the toolbar by dragging them out. Click Customize again to end customization. Open a new window. (Note: this isn't just a problem when re-starting the browser, customizations don't hold even for a new window.)


Actual results:

Icons for certain add-ons reappear in the toolbar of the new window (though not the window where I Customized).


Expected results:

I expected the icons I removed to stay removed. This doesn't happen with all add-ons icons (for example, Pinboard.in toolbar), but is happening with Lightbeam and Mailvelope.
(Reporter)

Updated

4 years ago
Component: Untriaged → Toolbars and Customization

Updated

4 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 854226
Hello Nick,

This should be fixed for Lightbeam shortly with bug 854226. Mailvelope will also be fixed if it's using our add-on SDK, otherwise you should contact the Mailvelope developer for them to fix the issue.
(Reporter)

Comment 3

4 years ago
Hmm... Mailvelope does use the add-on SDK, but when I re-build its FF add-on from source using the most recent add-on SDK (the master of which includes the fix for 854226 as of 20 minutes ago, right?), I still see the same unexpected behavior.

I had thought this wasn't a duplicate since it wasn't about enabling/disabling the plugin but just creating a new window, but I'm not familiar with the internals.

Comment 4

4 years ago
(In reply to nick from comment #3)
> Hmm... Mailvelope does use the add-on SDK, but when I re-build its FF add-on
> from source using the most recent add-on SDK (the master of which includes
> the fix for 854226 as of 20 minutes ago, right?), I still see the same
> unexpected behavior.
> 
> I had thought this wasn't a duplicate since it wasn't about
> enabling/disabling the plugin but just creating a new window, but I'm not
> familiar with the internals.

The SDK is builtin to Firefox now. I *think* cfx run will use the SDK from source, but I'm not 100% sure. Packaging the xpi from source won't use the SDK you packaged it with, but the SDK that's present in Firefox (for better or for worse...).
(Reporter)

Comment 5

4 years ago
(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to nick from comment #3)
> > Hmm... Mailvelope does use the add-on SDK, but when I re-build its FF add-on
> > from source using the most recent add-on SDK (the master of which includes
> > the fix for 854226 as of 20 minutes ago, right?), I still see the same
> > unexpected behavior.
> 
> The SDK is builtin to Firefox now. I *think* cfx run will use the SDK from
> source, but I'm not 100% sure. Packaging the xpi from source won't use the
> SDK you packaged it with, but the SDK that's present in Firefox (for better
> or for worse...).

Ah, I hadn't realized, thanks for the explanation. I had tested with an xpi packaged from source. I'll just wait for a new nightly with the fix in it to confirm that the issue is resolved.
You need to log in before you can comment on or make changes to this bug.