Meta bug to track the development of toolbar customisation as outlined by mpt's spec http://bugzilla.mozilla.org/attachment.cgi?id=65067&action=view

What should this depend on? Suggesting bug 15144, bug 48820, bug 48926, bug 49543, bug 89350, Bug 126321 (which is a weird one).

If this is a duplicate, please indicate original bug. Marking the dependencies I'm aware of. (I left out 126321 since it seems redundant.)

Fixing summary to make this findable or something like that. Let's eradicate this "seperate" abomination from the web, please.

I'd like clarification about the state of marlon's spec (or marlOn's review of mpt's spec, or whatever way you'd like to put it) and whether it should / shouldn't / may / may not influence the further progress of the issues tracked by this bug. This seems to block any progress on bug 15144, and /that/ seems to block progress on bug 48926 and bug 49543.

The component change was by mistake.

Don't forget bug 97023

bug 97023 is neither about customisation nor about separation. Jason already added quite a lot of dependencies, I think. ...which I'll comment on: bug 64678 - as far as I understood mpt, the component bar should die as well after having fulfilled the spec. Thus, I believe bug 64678 is an invalid (with an explanation why, of course) and *no* dependency. bug 78532 is solely about mailnews. I'm not sure if this bug includes mailnews (though the summary does not exclude it) or is only about Navigator.

> the component bar should die as well after having > fulfilled the spec. Thus, I believe bug 64678 is an invalid If you want to remove bug 64678 I won't object. In fact I'll remove it myself. I was following a trail of dependencies and sub-dependencies and may not have done enough checking in my selection of all bugs. Feel free to suggest others that were too-inclusive (and/or some I missed altogether). > bug 78532 is solely about mailnews. I'm not sure if this bug > includes mailnews This bug, I think, should include all toolbars and all buttons across all applications. > bug 97023 is neither about customisation nor about separation Agreed. Creating a new toolbar (or button) has no direct impact on this bug - which is about handling such objects in general, not about them in their specific substantiation.

Re: Additional Comment #8 From Jason Bassford 2002-07-12 18:16 ------- > > the component bar should die as well after having > > fulfilled the spec. Thus, I believe bug 64678 is an invalid > If you want to remove bug 64678 I won't object. In fact I'll remove it myself. > I was following a trail of dependencies and sub-dependencies and may not have > done enough checking in my selection of all bugs. Feel free to suggest others > that were too-inclusive (and/or some I missed altogether). I think the list is sufficient for the moment. Rather than adding any dependency that has the slightest relationship to this, we should concentrate on the most important dependencies first - namely bug 15144 and bug 49543. > > bug 78532 is solely about mailnews. I'm not sure if this bug > > includes mailnews > This bug, I think, should include all toolbars and all buttons across all > applications. Okay.

Taking time to look more closely at dependencies and removing those that really should not have been originally listed. (My fault for quickly doing up the list without sufficient checking.) Only those directly related to dynamically customizing toolbars / icons (individual real time choice) should be here - not necessarily those to do with usability. Changing the appearance of a particular button, adding a button that does a certain thing (outside of dynamic assignment), or changing the overall UI don't really belong. I notice that bug 115118 was added. I'm taking it out again since this is a bug that would affect the UI regardless of what was done in terms of adding buttons, moving toolbars, etc. It has no bearing on any of that requested functionality. It may have some bearing on bug 54943, but not on this tracking bug per se. I would like to request that whenever a bug dependency is added / removed from this point forward, that a comment is made listing its description and, perhaps, the reasoning behind the change. That way it makes it easier to track what's going on here. As such, I'll list the bugs I've taken off of the dependency list (more than half actually): bug 20306 - Can't open more than 2 windows with navigator button in component bar bug 33684 - add "Up" navigation command bug 52036 - Classic 'Go' and 'Search' buttons ugly appearance. bug 71138 - Add Bookmark button bug 84718 - [RFE] Add Find button to toolbar bug 89005 - [RFE] Browser needs an "Up" navigation button bug 89350 - Home button should appear on main Toolbar bug 91504 - Implement Complete and Correct Classic Theme on Mac bug 104125 - [RFE] Need one-click button for new browser window bug 115118 - RFE: dynamically expanding/contracting URL bar for low res users bug 154772 - [RFE] Tooltip for address bar should show complete current URL The above, while impacting toolbar UI, are not, I believe, directly related to implementing MPT's spec (although his spec, once implemented, will certainly allow for some of them to happen with or without the bugs themselves being specifically resolved: addition/removal of buttons, bug 15144, will, for instance, solve bug 89350). My apologies for any SPAM this is causing. I should have taken more time with the depencies originally.

> It may have some bearing on bug 54943 Make that bug 49543. <sigh> Marking this bug as blocking newly created bug 157415 - Add "Reset Toolbars" once customization is in place.

Attaching MPT's toolbar customization spec to this bug.

This bug should see attachments of patches and screenshots of fixes for its dependent bugs. Suggesting a standard naming convention for readability sake: Screenshot of fix for bug X. Patch for bug X. This helps track development of all sub patches. Also to be attached here could be a "meta patch", incorporating the patches from all of the dependent bugs.

I'm not quite sure if there's any point copying attachment 91339 [details] [diff] [review] to bug 49543 as Bugzilla will have linkified appropriate URLs into this comment.

You might want to edit the attachment in which case the link is http://bugzilla.mozilla.org/attachment.cgi?id=91339&action=edit

I think it's EVIL to attch non-reviewed patches to any other bug in a tracking bug. This only gives us a list of patches that nobody needs here. If we have patches that are OK and working for a big bunch of dependencies, and we merge them to a patch that can easily apply all the chages, then it might be OK to attach it here. Making double attchments to bug X and tracking bug Y is very BAD though, and doesn't help anything but bloat on the Bugzilla database.

The only way to make toolbar customization visible, and link all of the sub-components together properly, is to do it this way. It creates a single source to which anybody interested in MPT's spec can go and track progress. This whole issue deserves more attention than it's getting.

*** Bug 126321 has been marked as a duplicate of this bug. ***

The general consensus appears to be that attachments should not be added at all to this tracking bug. I can find at least one exception: Screenshots showing a (more or less) complete implementation of at least two of the bugs tracked here should be posted in this bug, as they are not directly related to *one* of the bugs.

Added bug 158144 - Resizable toolbars. - to dependency list.

Correction (apologies): bug 158544 added.

This bug report is (1) a duplicate of <http://bugzilla.mozilla.org/showdependencytree.cgi?id=49543>, and (2) *not* a blocker for bug 157415 (`Reset Toolbars' will be useful once pretty much *any* toolbar customization is implemented). Please just bookmark the above link, instead of spamming people with an extra tracker bug. Thanks.

This is not a duplicate of that. Adding a specific button has nothing to do with this bug (bug 71138 as listed has nothing directly to do with bugs that allow for dynamic configurability.) This is a tracking bug, that is not. > *not* a blocker for bug 157415 Yes it is. Reinstating. There is *currently* no real reason for it to be solved. But once the other pieces fall into place, then it will have a purpose. What you're saying is that you can go to the store and by baby diapers at a point after you've started buying other items in preparation for its delivery. But it really makes more sense that "buying diapers" depends on the actual event itself (delivery) more than anything else. Hence, once all of the other elements are configurable (splitting toolbars AND horizontally configurable toolbars) then we'll want to resize them. I know of know way of making a bug dependent on 2 other bugs being fixed *at the same time* , so making it dependent on this tracking bug is more appropriate.

Shouldn't bug 161032 be added to the dependency list of this bug? And if that one is fixed, won't many of the bugs that are being tracked by this one become obsolete?

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This is a tracking bug, so it's no wonder there haven't been any comments. Some of the dependencies have had recent activity, so I'm setting this back to NEW.