554279 - Restarting Firefox resets the toolbar customizations

Status: VERIFIED FIXED

(Toolkit :: Toolbars and Toolbar Customization, defect, P2)

Description

[Ori Avtalion (salty-horse)]

Starting with the 2010-03-17 nightlies, every time a different nightly is ran on a profile, the toolbar customizations are reset.

To reproduce:
1) Download the nightly build from 2010-03-17.
2) Run it on a new profile, e.g. "toolbar".
3) Customize the toolbars and add a "Downloads" button next to the home icon.
4) Restart the browser -- the icon is in place. Close the browser
5) Download and run the 2010-03-18 on the "toolbar" profile.
6) The "Downloads" button will be gone. The customizations will be reset to the defaults.

Making the change on any nightly from 03-17+ and then testing on it on *any other* nightly from that group will cause the customizations to reset.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Can you please tell us your complete user agent string so we will know which branch you are using? thanks.

Comment 2

[Ori Avtalion (salty-horse)]

I'm using:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a4pre) Gecko/20100322 Minefield/3.7a4pre

The nightlies to test were downloaded from the "mozilla-central" builds, e.g.:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-03-19-03-mozilla-central/firefox-3.7a4pre.en-US.linux-x86_64.tar.bz2

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Changeset for both builds:

PASS: http://hg.mozilla.org/mozilla-central/rev/16a974dd72e1
FAIL: http://hg.mozilla.org/mozilla-central/rev/2cc5ad2cf917

Changes: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16a974dd72e1&tochange=2cc5ad2cf917

I can't find a check-in which plays in that area. Dao, could the tabbed browsing changes be related somehow?

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16a974dd72e1&tochange=2cc5ad2cf917
> 
> I can't find a check-in which plays in that area. Dao, could the tabbed
> browsing changes be related somehow?

Which tabbed browsing changes specifically?

Has anyone reproduced this in a profile without extensions?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #4)
> Which tabbed browsing changes specifically?

I think of bug 347930.

> Has anyone reproduced this in a profile without extensions?

When you test in Safe Mode please also check if the regression range above is correct. Thanks.

Comment 8

[WildcatRay]

(In reply to comment #6)
> *** Bug 554310 has been marked as a duplicate of this bug. ***

As mentioned in Bug 554310, I first started seeing this in the win32 Minefield/Trunk nightly of 20100317 ((Build: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.9.3a4pre) Gecko/20100317 Minefield/3.7a4pre - Build ID:
20100317041424 built from http://hg.mozilla.org/mozilla-central/rev/16a974dd72e1).

The most consistent time of occurrence is when starting Minefield after a cold bootup--cold bootup being turning on the computer after being shut off like I do overnight.

Also, as I have stated in Bug 554310, I have not been able to isolate this to a particular extension. I did disable all extensions and one by one re-enabled them. Each time, the toolbar did not reset. (In my testing, I placed a flexible space between the stop and reload buttons to force both of them to show and removed from the nav toolbar the Home button which I do not use.)

In the Add-Mgr. all installed extensions appear to be enabled. Those that add Status Bar items are there and functional. Extension-added menu items are still there and functional. (I have used the Restart Minefield File menu item that MR Tech Toolkit provides.)

What is not available are any toolbar buttons that extensions add in the Customize... dialog and thus are not available to add to the nav toolbar.

However, if/when this does crop up, a simple restart "fixes" things except that I still have to redo my nav toolbar customizations.

What is different about starting Minefield after a cold boot versus restarting from within the browser and closing and then starting it, again?

Comment 9

[eyal gruss]

this happens for me also after installing/uninstalling/enabling/disabling add-ons

Comment 10

[siegfre]

Note: I opened/closed bugzilla # 553395 because I was seeing the same problem.  I was able to isolate it to a particular extension: Hostname In Toolbar 1.06 and it's interaction with Dictionary Tooltip.  I'm not sure what the fix was for Hostname In Toolbar but the fix resolved the problem.  It sounds like there may be otheer extensions that may have uncovered this bug.

Comment 11

[Jenn Scott]

Other extensions indeed do seem to be related to this bug, from what Mozillazine users are reporting.  Extensions that triggered this include PDF Download, Intelligent Middle Clickums, AutoPager Lite, Zoom Page, Firesomething, and Titlebar Tweaks.  Some of those are woefully out of date (but still worked), while others did work with previous 3.7a versions, so there's no correlation I see on that end.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #7)
> (In reply to comment #4)
> > Which tabbed browsing changes specifically?
> 
> I think of bug 347930.

Dao, did this make the Wed Mar 17 build?

Comment 13

[Dão Gottwald [:dao]]

(In reply to comment #12)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > Which tabbed browsing changes specifically?
> > 
> > I think of bug 347930.
> 
> Dao, did this make the Wed Mar 17 build?

Yes.

Comment 14

[Dão Gottwald [:dao]]

The problem or part of it appears to be that extensions trigger the toolbar constructors before XUL overlays for <toolbarpalette id="BrowserToolbarPalette"> are loaded. Consequentially all extension items are missing. Just accessing gNavToolbox early enough triggers this, and so does accessing gBrowser since the tab strip is in a toolbar.

(In reply to comment #10)
> I was able to isolate it to a particular extension: Hostname In Toolbar 1.06
> and it's interaction with Dictionary Tooltip.  I'm not sure what the fix was
> for Hostname In Toolbar but the fix resolved the problem.

The fix for "Hostname in Titlebar" looks like this:

>-hostnameInTitlebar.setUpdateTitlebar();
>+window.addEventListener("load", function() { hostnameInTitlebar.setUpdateTitlebar(); }, false);

The first thing hostnameInTitlebar.setUpdateTitlebar does is to access document.getElementById("content"), i.e. gBrowser.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor, but why does it affect the other toolbars as well?

Comment 16

[tabmix.onemen]

Is it possible to move tabContextMenu out from tabbrowser-tabs and put it into 
mainPopupSet.

there are many extensions that add menu item into tabContextMenu

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Bug 554165 will help that by re-adding an mStrip accessor for compat, and adding a gBrowser.tabContextMenu property.

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #15)
> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
> but why does it affect the other toolbars as well?

The toolbar being constructed first sets toolbox.palette and removes the toolbarpalette element from the document.

Comment 19

[Jelle Geerts]

As the author of the Hostname in Titlebar extension, I feel obliged to post my findings while fixing this bug.

I received an e-mail from a noble user (siegfre) who told me this problem was most likely related to using the Dictionary Tooltip add-on in conjunction with my add-on.

Experimenting with the Firefox 3.7a4pre build revealed that on a clean build, installing Hostname in Titlebar would *usually* cause the toolbar customizations to be lost at the first next start of Firefox, though *usually* they would be OK again at subsequent launches. It also sometimes occurred that after a few restarts the customizations were still not back.

So to me, whether or not it will work, seems just a timing issue. Though I don't know enough about Firefox' internals to judge with more accuracy.

I'm not quite sure what causes this behavior, but found a workaround nonetheless. However, I am still curious to find the cause of the issue.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #19)
see bug 554279

Comment 21

[Dão Gottwald [:dao]]

(In reply to comment #20)
> (In reply to comment #19)
> see bug 554279

Uh, sorry, we're in bug 554279... I thought you commented somewhere else.

Comment 22

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #16)
> Is it possible to move tabContextMenu out from tabbrowser-tabs and put it into 
> mainPopupSet.

Filed bug 554991 for that.

Comment 23

[[not reading bugmail]]

This bug is annoying enough that I finally decided to uninstall all of my add-ons, which then I don't see this issue with a default install with standard custom icons.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dao, have you accidentally removed the regression keyword?

Comment 25

[Dão Gottwald [:dao]]

No. The underlying issue is not a regression. See comment 14.

Comment 26

[Dão Gottwald [:dao]]

This comment seems relevant, especially bz's addition:

> If we have not yet displayed the document for the first time
> (i.e. we came in here as the result of a dynamic overlay load
> which was spawned by a binding-attached event caused by
> StartLayout() on the master prototype - we must remember that
> this overlay has been merged and tell the listeners after
> StartLayout() is completely finished rather than doing so
> immediately - otherwise we may be executing code that needs to
> access XBL Binding implementations on nodes for which frames
> have not yet been constructed because their bindings have not
> yet been attached. This can be a race condition because dynamic
> overlay loading can take varying amounts of time depending on
> whether or not the overlay prototype is in the XUL cache. The
> most likely effect of this bug is odd UI initialization due to
> methods and properties that do not work.
> XXXbz really, we shouldn't be firing binding constructors
> until after StartLayout returns! 

http://hg.mozilla.org/mozilla-central/annotate/87f8bdc77722/content/xul/document/src/nsXULDocument.cpp#l3216

Comment 27

[Justin Wood (:Callek)]

(In reply to comment #25)
> No. The underlying issue is not a regression. See comment 14.

I have to admit, the user-facing issue is a major regression. Does it really matter if a change on our end made the "non-regression" part that _causes_ the user-facing part to be MUCH MUCH more common?

I'd still consider this a regression due to that.

Comment 28

[eyal gruss]

on the latest builds, restarting twice seems to restore the lost toolbar customizations

Comment 30

[Jesse Ruderman]

As reported and summarized, this is a regression.  I suppose you could say it depends on a XUL bug that is not a regression.

Comment 31

[Dão Gottwald [:dao]]

(In reply to comment #30)
> As reported and summarized, this is a regression.

No, the bug as summarized was there before. See bug 557603 for instance.

> I suppose you could say it
> depends on a XUL bug that is not a regression.

There's no such separate bug, and I don't think we need one, it's this one (see product and component).

Comment 32

[kulmegil]

This bug reproduces (almost) always with Tree Style Tab extension enabled.

Comment 33

[Igor Velkov]

(In reply to comment #32)
> This bug reproduces (almost) always with Tree Style Tab extension enabled.

I have this bug without Tree Style Tab extension

Comment 34

[Sergyk]

when its bug will be fix, guys?

Comment 35

[Sergyk]

maybe its help, toolbar resets to default when I'm using all in  one sidebar or gmail notifer. When they are torn off all is ok.

Comment 36

[Martin Pelant]

Ithis bugs is better in 4.0b1 (the toolbar resets itself only when I add new addon or update existing one) but in 4.0b2 candidate 1 the toolbar resets itself after each restart

Comment 37

[WildcatRay]

Since Bug 568691 - Use manifests and data tables to register XPCOM components landed, I have not seen this bug on my WinXP system. Prior to this landing, when I updated my nightly or added/updated any add-ons, my toolbars would reset forcing me to restart the browser another time so I could then redo my toolbar buttons and their arrangement.

Comment 38

[Alice0775 White]

Attachment: testcase extension

This testcase extension is *WRONG*. 

Prior to completion of DOM browser.xul, the extension accesses property of browser element. 

Toolbar will be reset due to this wrong extension.

Comment 39

[Alice0775 White]

Many extension such as "Hostname In Toolbar" extension  is wrong.
And such wrong extension are registered in AMO.

These wrong extension did not consider completion of DOM (ex. window.addEventListener('load',xxxx, false);)

So, I think this is extension's issue.

Comment 40

[Jelle Geerts]

@Alice0775 White:
Allow me to correct you on that: the latest version of my Hostname in Titlebar addon actually uses the addEventListener() method.

Comment 41

[Michael Lefevre]

Well, if this is an extension issue, then that needs to be communicated more effectively to extension authors.

Comment 42

[Dão Gottwald [:dao]]

It's triggered by extensions, but it's not clear that extensions behaving this way /should/ trigger this bug. See comment 14 and comment 26.

Comment 43

[WildcatRay]

(In reply to comment #42)
> It's triggered by extensions, but it's not clear that extensions behaving this
> way /should/ trigger this bug. See comment 14 and comment 26.

I'm not sure if my observations are relevant, but I recently bought a new Win7 computer prior to the landing of Bug 568691 I mentioned in Comment 37 above. It is much faster than my WinXP system. I did not see this bug in my newer system, so, FWIW, this suggests that individual system processing speed is a factor with this bug.

Comment 44

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to comment #38)
> Created attachment 460137 [details]
> testcase extension
> 
> This testcase extension is *WRONG*. 

So, the problem is triggered when add-ons access certain browser elements before the load event. This is clearly a regression because it never happened before. However, if there's no way to return things to exactly the same way they were before, I would agree with making these add-ons break, rather than let them break the UI due to bad practices. FWIW, all XUL tutorials I've seen use the load event instead of just running the code when the file is loaded.

We are already communicating many breaking changes for Firefox 4, and we can add this to the list when we know what needs to be changed.

Comment 45

[Dão Gottwald [:dao]]

(In reply to comment #44)
> (In reply to comment #38)
> > Created attachment 460137 [details] [details]
> > testcase extension
> > 
> > This testcase extension is *WRONG*. 
> 
> So, the problem is triggered when add-ons access certain browser elements
> before the load event. This is clearly a regression because it never happened
> before.

It did happen before. Please read the comments previously made in this bug.

Comment 46

[Jorge Villalobos [:jorgev] (he/him)]

I did read all the comments before posting. Which one are your referring to?

Comment 47

[Dão Gottwald [:dao]]

comment 14, comment 26, comment 31.

Comment 48

[Jorge Villalobos [:jorgev] (he/him)]

Does that mean you have reproduced this bug in 3.6?

Comment 49

[Dão Gottwald [:dao]]

As far as I remember, back in March I reproduced this in older builds, possibly in 3.6, by accessing gNavToolbox early.

Comment 50

[YUKI "Piro" Hiroshi]

comment #32, comment #33
Tree Style Tab really caused this problem on Minefield 4.0b2pre, and it was fixed on TST 0.10.2010070301. (This was verified by Alice0775.)
changeset: http://www.cozmixng.org/retro/projects/piro/changesets/6796

Comment 51

[msth67]

(In reply to comment #36)
> Ithis bugs is better in 4.0b1 (the toolbar resets itself only when I add new
> addon or update existing one) but in 4.0b2 candidate 1 the toolbar resets
> itself after each restart

It has happened so far occasionally to me in 4.0b4,on restart after choosing the "remember windows & tabs from last time" option (and then just clicking exit,not "save & quit"),some extensions buttons were lost and the bookmarks button was relocated to the right edge of the toolbar - it has however never happened in the previous releases I've been using (b2 and b3:not sure about b2,but b3 had exactly the same extensions installed).

(In reply to comment #35)
> maybe its help, toolbar resets to default when I'm using all in  one sidebar or
> gmail notifer. When they are torn off all is ok.

This made me think that I have the Feed sidebar extension,but I also had it in b3 and this toolbar resetting did never happen,not once.

Comment 52

[msth67]

It also seems related in some way (or,they often happen at the same time) to this other bug https://bugzilla.mozilla.org/show_bug.cgi?id=590381 
in which ,with two windows each with multiple tabs (one window also including app tabs),tabs freeze on browser restart-as far as I can tell,tab freezing has always been linked to toolbar resetting,but toolbar resetting can also happen on its own.

Comment 53

[Jorge Luis]

I've just register to Bugzilla, i'm not a bug fixer or something like that. But i want to say: because of this malfunction/bug? i made and app to replace localstore.rdf with my own customized file before each startup. Then, the toolbar shows the right icons on each startup. I looks like the problem is when Firefox is closing or when an icon is added (i don't know the last one) and not when Firefox is loading (If that what is said in <a href="show_bug.cgi?id=554279#c14">comment 14</a>? if not, sorry my mistake)

Comment 54

[Sergey Sokoloff]

> ...if there's no way to return things to exactly the same way
> they were before, I would agree with making these add-ons break, rather than
> let them break the UI due to bad practices. FWIW, all XUL tutorials I've seen
> use the load event instead of just running the code when the file is loaded.

They are probably breaking toolbar settings for the other extensions as well, that's the problem. For example, when I encounter that unpleasant effect in Firefox 4 beta 4, I loose all toolbar buttons, it does not matter if they were from uncompatible extensions, or compatible, or dragged on (or out of) the toolbar by me manually.

Comment 55

[Brian Carpenter [:geeknik]]

I wasn't having this problem very often with the nightly builds of Minefield up until about a week ago and now every time the browser is restarted, my stop/reload button is moved back to the default position, various extension buttons I've placed right of the search box are gone (even missing from the customize pop up).

Comment 57

[Ravi]

Hi all,
This bug is still present in Minefield 4.08bpre. It always resets my toolbar. Additionally, what is frustrating is that everytime, I start up Minefield 4.08bpre, updater runs and it "updates" to Minefield 4.08bpre. Installs and then my toolbar customizing is lost. 

Is there a solution to this ?
Here is some troubleshooting information:

  Application Basics

        Name
        Firefox

        Version
        4.0b8pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101213 Firefox/4.0b8pre


  Extensions

        Name        					Version        Enabled        ID

        Launchy        					4.4.0        	true        [e-mail]

        PDF Download   					3.0.0.1      	true        {37E4D8EA-8BDA-4831-8EA1-89053939A250}

        Download Statusbar      			0.9.7.2        	true        {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}

        Mozilla Labs: Prospector - Find Suggest    	4        	true        [e-mail]

        Mozilla Labs: Prospector - Speak Words     	3        	true        [e-mail]

        Mozilla Labs: Prospector - Query Stats     	2.2        	false        [e-mail]

        NoScript        				2.0.7        	true        {73a6fe31-595d-460b-a920-fcc0f8843232}

        Mozilla Labs: Prospector - Instant Preview        2        	true        [e-mail]

        Omnibar        					0.7.2.20100912	false        [e-mail]

        Gmail Watcher        				1.30        	false        gmailwatcher@sonthakit

        Adblock Plus        				1.3.2        	true        {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

  Modified Preferences

      	Name      							Value

        browser.places.smartBookmarksVersion        			2

        browser.startup.homepage_override.buildID        		20101213030326

        browser.startup.homepage_override.mstone        		rv:2.0b8pre

        browser.tabs.warnOnClose        				false

        extensions.lastAppVersion        				4.0b8pre

        network.cookie.prefsMigrated        				true

        places.history.expiration.transient_current_max_pages        	63363

        privacy.sanitize.migrateFx3Prefs        			true

        security.disable_button.openCertManager        			false

        security.enable_ssl2        					true

        security.warn_viewing_mixed        				false

  Graphics

        Adapter Description
        NVIDIA Quadro NVS 140M

        Vendor ID
        10de

        Device ID
        0429

        Adapter RAM
        128

        Adapter Drivers
        nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

        Driver Version
        8.16.11.8694

        Driver Date
        9-5-2009

        Direct2D Enabled
        true

        DirectWrite Enabled
        true

      GPU Accelerated Windows
      1/1 Direct3D 10


Thanks and Regards,
Ravi

Comment 58

[Paul [pwd]]

(In reply to comment #57)
Are you still seeing this with a clean profile?

Comment 59

[Michael Lefevre]

(In reply to comment #58)
> (In reply to comment #57)
> Are you still seeing this with a clean profile?

Seems unlikely, given that this bug is known to be triggered by extensions. However, I don't think further comments reporting the issue are needed - it seems the cause is understood already, and the bug is not fixed yet.

Comment 60

[Paul [pwd]]

(In reply to comment #59)
> (In reply to comment #58)
> > (In reply to comment #57)
> > Are you still seeing this with a clean profile?
> 
> Seems unlikely, given that this bug is known to be triggered by extensions.
> However, I don't think further comments reporting the issue are needed - it
> seems the cause is understood already, and the bug is not fixed yet.

It would be at least helpful if the offending extension could be reported.

Comment 61

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Not a blocker.

Is this really a XUL bug? Comment 14 doesn't give a reason for why it is.

Comment 62

[Paul [pwd]]

(In reply to comment #61)
> Not a blocker.
> 
> Is this really a XUL bug? Comment 14 doesn't give a reason for why it is.

If we're knowingly allowing extensions to trigger this, then this is most certainly a blocker. Especially if we're relying on extensions to delay certain code initialisation to avoid this.

Comment 63

[Michael Lefevre]

I cannot imagine how "restarting Firefox resets toolbar customizations" is not a blocker (and I doubt that is what was meant). This is a serious issue, and the effect of it has become a lot more serious since 3.6, even if the fact that there was previously less serious symptoms caused by the same underlying code problem means that this doesn't technically qualify as a regression.

Would it help to leave this bug and file a new clean bug to consider what to do for Firefox 4?

Comment 64

[Boris Zbarsky [:bzbarsky]]

To be clear, as a core XUL bug this is not a blocker (and imo is wontfix).  This sounds like just a contradictory set of assumptions being made by extensions and some of our UI bindings.  Maybe we can fix the latter to not make those assumptions; Dão would know better than I.  If so, this bug should be moved to Toolkit, presumably, right?

Comment 65

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Moving this to toolkit so that it doesn't fall between the cracks.

Comment 66

[Philip Chee]

> Dão Gottwald      2010-03-24 12:43:15 PDT
> 
> (In reply to comment #15)
>> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
>> but why does it affect the other toolbars as well?
> 
> The toolbar being constructed first sets toolbox.palette and removes the
> toolbarpalette element from the document.

Dão,

The seamonkey toolbar bindings puts the palette initialization code in the toolbox binding:

<http://mxr.mozilla.org/comm-central/source/suite/common/bindings/toolbar.xml?mark=80-82#69>

Would this help? We also don't remove the <toolbarpalette> from the DOM removing the need to null check various stuff such as gURLBar.

Comment 67

[Dão Gottwald [:dao]]

(In reply to comment #66)
> > Dão Gottwald      2010-03-24 12:43:15 PDT
> > 
> > (In reply to comment #15)
> >> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
> >> but why does it affect the other toolbars as well?
> > 
> > The toolbar being constructed first sets toolbox.palette and removes the
> > toolbarpalette element from the document.
> 
> Dão,
> 
> The seamonkey toolbar bindings puts the palette initialization code in the
> toolbox binding:
> 
> <http://mxr.mozilla.org/comm-central/source/suite/common/bindings/toolbar.xml?mark=80-82#69>
> 
> Would this help?

The toolbar constructor accesses the toolbox, so that wouldn't make a difference.

> We also don't remove the <toolbarpalette> from the DOM
> removing the need to null check various stuff such as gURLBar.

Wouldn't help, as the toolbars would still be populated before the overlays are loaded.

Comment 68

[Dão Gottwald [:dao]]

Attachment: patch

This seems to help. (Thanks for the test extension, Alice!)
I sent this to the try server. I wouldn't be surprised if it breaks some tests.
I also wouldn't be surprised if it breaks extensions making assumptions about when toolbars are initialized...

Comment 69

[Dão Gottwald [:dao]]

Attachment: patch

I thought pageshow fired before load, but it doesn't... readystatechange does.

Comment 70

[Neil Deakin]

Comment on attachment 497683 [details] [diff] [review]
patch

The test doesn't check this bug right?

Comment 71

[Dão Gottwald [:dao]]

Attachment: patch (test added)

test_toolbar.xul wasn't testing this. I also didn't want to add complexity there, so I added a dedicated test for this.

Comment 72

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/e9b1ad4ad23b

Comment 74

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre.

Dao, I assume we don't need a manual test here in favor of the automated one which has been checked-in. If not please request in-litmus addition.

Comment 75

[Mac]

This bug has returned in Firefox 4 and also Firefox 5.

I have firefox 5, 32 bit version on Windows 7 and I had this problem with both 4 and 5. I have even created a new FF profile and it did not help.

I customize my toolbar, add a few buttons from "Google toolbar" and replace the toolbar with Google's. After restart everything has returned to beginning.

These guys here confirm the bug.

http://support.mozilla.com/en-US/questions/808671