I think this is probably a regression from bug 414864, but I haven't confirmed it. STR: 1) default profile, move the stop button the the personal toolbar 2) click "Restore default set" The stop button will disappear. Click "restore defaults" again, and it will be properly replaced in the navigation toolbar. I think what's happening is that we are restoring the default set of the navigation toolbar first (because we restore toolbars in document order), and when it tries to add the reload button, it hits http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/toolbar.xml&rev=1.45&mark=226#195 , because the element is present in the document. Dao, can we revert the patch for bug 414864 now that we've undone the ID changes (bug 415099)? I don't exactly recall why we needed that patch in the first place.

(In reply to comment #0) > I don't exactly recall why we needed that patch in the > first place. Because as you say we changed the id of the navigation toolbar. If you put an element from that toolbar's defaultset on the menu bar, where the id hasn't been changed, you get the element twice. It still seems wrong that toolbar.xml can do that, but if the fix caused this bug, we should take it out.

I'll check if reverting the patch fixes this.

Comment on attachment 310627 [details] [diff] [review] patch Thanks Dao.

Comment on attachment 310627 [details] [diff] [review] patch a=beltzner

Checking in toolkit/content/widgets/toolbar.xml; /cvsroot/mozilla/toolkit/content/widgets/toolbar.xml,v <-- toolbar.xml new revision: 1.46; previous revision: 1.45 done

This now works for me with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre . Tried moving stop button and home button around, and they now revert with one click as they should.