Closed Bug 643929 Opened 13 years ago Closed 10 years ago

'Add New Toolbar' function broken in Firefox 4, custom toolbars not persistent

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Version:
4.0 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mark.a.craig, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

The 'Add New Toolbar' function in Customize appears to be broken in Firefox 4: any custom toolbars created are not persistent.  This also affects upgrades from previous Firefox (3.x at least) versions where custom toolbars were already present and persistent: they disappear completely.

Reproducible: Always

Steps to Reproduce:
1. Customize...
2. Add New Toolbar;
3. drag some icons to the new toolbar from Customize... list;
4. exit Firefox 4;
5. restart Firefox and note that (a) custom toolbar is not displayed and (b) custom toolbar is not even listed in Customize... context menu.
Actual Results:  
I wasted half an hour recreating a heavily customized toolbar that was lost in the upgrade from Firefox 3.6.x to Firefox 4; I assumed that the upgrade simply required a new paradigm (though it would have still been rude and high-handed not to WARN me of such).  However, upon creating a new toolbar in Firefox 4, I exited and restarted the browser and the toolbar had completely disappeared, all traces of it.  I duplicated this process repeatedly.

Expected Results:  
Custom toolbars should be persistent, obviously... what else is the point of a toobar?
I was tempted to simply piggyback this onto bug report #319196, but it's an OLD report and not really describing the identical problem.
Works for me

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110322 Firefox/4.0b13pre ID:20110322030409
I can add icons to existing toolbars, and those are persistent.  It is new toolbars that are not.
Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110322 Firefox/4.0b13pre

Works for me. Please try if it works fine by creating a new profile. 
https://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile.
I already had an existing 'pristine' profile... but I didn't think to try it. *facepalm*  I just did, and the toolbar I created was persistent with that profile.

What could cause this bad behavior?  Could it possibly be an extension?  Could it be that I'm sync'ing the entire profile using Dropbox and a symlink?  Wait, no... can't be that last, because I implemented that after the upgrade (and some research) but my existing pre-4.0 custom toolbar had already disappeared.  Must be an extension, but which one?  Any clues as to what sort of extension might be capable of this effect?
I see this same problem but on Linux.

It's also been reported here: http://forums.mozillazine.org/viewtopic.php?f=23&t=2137787

New Linux installs, with new Firefox installs & clean/new profiles on

  opensuse11.4/kde/x86_64
  opensuse11.4/kde/i586
  fedora14/kde/x86_64

all exhibit the same behavior.

Reproducible: Always

Steps to Reproduce:
1. start Firefox 4
2. Right-click to Customize Toolbars
3. Add New Toolbar
4. Drag the LocationBar to the new toolbar
5. exit Firefox 4
6. restart Firefox 4

The 'added' toolbar is not displayed, and not available in any context menu.
The mozillazine post hast been moved to their 'Bugs' forum:
http://forums.mozillazine.org/viewtopic.php?f=9&t=2137787
I have identified the cause of this behavior in my environment: the Skipscreen extension.  It claims to be compatible with Firefox 4, but it causes this.

It previously worked fine in 3.6.x.  I dunno WHAT they have managed to do that breaks the toolbar system like this.
So can anyone else who has reported here this specific problem confirm that they also have the Skipscreen extension installed?  If an extension can trigger it, it's entirely possible that there might be more than one that does so.
Fyi, as above, I see this behavior in:

  New Linux installs, with new Firefox installs & clean/new profiles ..

with NO additionally-installed extensions.

And in the instances of 'full blown' installs with lots of extensions, where this problem still exists, I've never used or installed the Skipscreen extension.
and for completeness

  Start FF4 in SafeMode
  Add & populate new toolbard
  Close FF4

and then either

 Re-start FF4 in SafeMode

or

 Re-start FF4 in normal user mode

the problem still exists as reported
DChil, you will certainly help to keep my bug report alive. :-)

Apparently there are indeed multiple triggers of this behavior, and not all of
them require a misbehaving extension.
I upgraded FF 3.6.x -> 4.0 running in a Win7/64 VirtualBox VM.

FF4 in Win7, for me, does NOT exhibit this problem.  New-installed toolbars survive restart.

So, in my case, problem only on various Linux flavors.
Version: unspecified → 4.0 Branch
I noticed Tim changed the version property of this report, and that gave me pause to skim the others for relevance.  Since DChil also reported observing the behavior but in Linux, shouldn't the Platform property be changed to something other than "Windows 7"?  "x86_64" still seems relevant, since he was apparently also using a 64-bit system and Linux distros.

As for me, I haven't observed this or been affected by it since I removed the misbehaving extension, SkipScreen.  As I theorized earlier, though, I would expect there might be other extensions capable of causing the same behavior.  There's a (XUL?) hole that needs to be plugged to prevent extensions being able to trigger it, and probably other triggers unrelated to extensions (per DChil) as well.
I have had this problem repeatedly.  I have a new profile and a in a safestart the problem is recreated with the steps that were listed in the bug report.

And I am using a MAC!  10.6.7.  I also had the samething happen under 10.4 and ff 3.6.11

bobie
I get this too at "random" restarts. There seems to be no pattern - though I am sure there is somewhere!!

Happened only after upgrade to Firefox 4. Tried new local stores, new profiles, extensions etc.

If I add Google Toolbar, this cause my custom toolbar to disappear.

If I add AIS toolbar, this causes it to disappear.

Seems to be addons that amend / change toolbars.
I have not observed a recurrence of this behavior since I uninstalled the Skipscreen extension that triggered it.  MAWallace seems to have found other addons that trigger it.
The custom toolbars are always visible on restart here. These toolbars ignore the (correctly set) collapsed attributes in the localstore.rdf file.

Firefox 4.0.1 with no extensions
Windows XP SP3 32-bit
After a long absence, this problem is back.
I did not see it for over a year, but as more addons become restartless,
it seems to be getting more common. 
1. many addons add icons to the add-on bar. Some of these icons, if moved to a user-created toolbar, will wipe out all of the icons to the right of the moved icon. If moved to the LEFT of a toolbar, the toolbar will go away forever when you restart.
2. upgrading from ff27b6 to ff27b7 - my new toolbar is gone.
3. several times for no obvious reason.

Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20140116125114 CSet: f42890df825c

The UI should not be throwing away toolbars if something fails.
Perhaps the UI could keep a backup of each toolbar, and if all else fails, revert the toolbar with the problem.
bug 617545 mentions adding the firebug add-on destroying new toolbars

bug 748118 mentions addon DragIt temporarily destroying new toolbars until it is removed or disabled. 

Please mark this bug as confirmed.

The fragility of the toolbar UI code appears to be many years old; Maybe recent changes made it easier to trigger this bug.
Searches NOT finding this bug: 
toolbar removed
toolbar deleted
toolbar gone
Is this an Issue with Australis enabled builds (i.e. Nightly) too?
More addons that trigger this:
HTTPtoHTTPS - https://addons.mozilla.org/en-US/firefox/addon/httptohttps/
by moving button to new toolbar
MemChaser - https://addons.mozilla.org/en-US/firefox/addon/memchaser/
by moving message box/button to new toolbar

will try a nightly ASAP.
Not sure about Nightly, no sign of any add-on bar in ff29a1 OR 
any way to add a new toolbar AFAIKT. 
The icon for Adblock+ DID vanish completely, so it has a possibly-related, 
but clearly worse problem. 
(At least on ff27b7 I can re-add the missing buttons)
upgraded AB+, now icon is ok.
So far, Memchaser 0.5.2.1 is ok on any of the existing toolbars on Nightly ff29a1.
Also httpToHttps looks ok, but you can't make a new toolbar on Nightly, 
so the conclusion is incomplete. 

For completeness: on ff27b7: if you make a new toolbar, drag the url box to it, 
disable compatibility checking, then install the ancient neo diggler,
the toolbar vanishes on restart, and you can't type a url.
Save text to file : also blows out all icons to its right if moved to a toolbar.

FYI: I have iceweasel 24.2.0, esr handy, and it also loses icons.
on Mac, see Comment 15, and Linux. platform -> all? 

Opening a new window sometimes the new window has lost the new bar.
I just upgraded from ff27b7 to ff27b8, 
and once again all custom toolbars have vanished.

Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20140120132616 CSet: c1ef58534e98
Lost a toolbar again on restart, it had only the location box.
The profile was new on ff27b6.
Now a restart of ff27b8 with 1 toolbar same as before, ok. 

Started a new profile now for ff27b8, so far single new toolbar survives.
Please update Version from 4.0 branch to 27.0 branch, still losing toolbars repeatedly after upg from ff27b9 to 27 release:
Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20140127194636 CSet: b8896fee530d
lost 2 new toolbars with flex-space only.

Please update platform to All (Win, Mac, and 2 of us on Linux, one x86-64, and my i686 on debian) 
I have seen this on many different versions, not just 4 and 27.
I had Icon/button/box/spacer/bar loss but empty bar remains on ff24, and ff26: 
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20131205075310 CSet: 39faf812aaec
on a new profile with 3 addons.

I have never used the skipscreen extension either.

I hope mozilla* will encourage all extension writers to test their addons
with a custom toolbar, with all their new items on it.

We need a file with all toolbar info so we can back it up daily, 
restore on any such accident - or when a new profile is forced on us by some random fluke (e.g. amazon.com buttons stopped working) - It takes many hours to reinstall 50-100 addons and re-add 100+ buttons to the toolbars.
Another new culprit: "The addon bar (restored)" hides all new toolbars until it is disabled; then they return.
Likely responsible for comment 31 fail.
It is NOT involved in previous fails - not used previously except on ff29, which has no "add new toolbar".
It reliably removes all new toolbars, and was not involved in the losses on updating ff27beta*.
An unconfirmed, but possible - and very rare - culprit:
Vertical Toolbar, on first install, will remove the print icon from whatever toolbar it is on.
IF a new toolbar has ONLY a print icon, and nothing else, not even a spacer, the toolbar could be 
deleted for being empty on some Ffox versions. Disable/re-enable did NOT repeat the delete.
Upgrade 27 to 27.0.1, new toolbar with location box, is gone again.
It makes no sense to give "still broken" reports since this feature ("Add New Toolbar") will be gone in Firefox 29+ due to Australis => resolving.

Please
* do not reopen
* comment further on of why this feature has been removed etc. pp. since it happened elsewhere. Rather try https://groups.google.com/forum/#!forum/firefox-dev
Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I installed the extension Classic Theme Restorer, and now I have several additional toolbars that are persistent.
You need to log in before you can comment on or make changes to this bug.