Closed Bug 49543 Opened 25 years ago Closed 16 years ago

Separate Toolbar from Address Bar [urlbar]

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mpt, Assigned: jag+mozilla)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [geekweb-fixed])

Attachments

(4 files, 15 obsolete files)

(deleted), image/gif
Details
(deleted), patch
Details | Diff | Splinter Review
(deleted), text/html
Details
(deleted), patch
Details | Diff | Splinter Review
At the moment, the Command Toolbar (featuring Back, Forward, Reload, and Stop buttons) and the Location Toolbar (featuring location field and `Search' button) are combined into a single `Navigation Toolbar'. This limits users' ability to customize the interface to suit them: * they may want browsing controls and other buttons (like `Print' and `Text Size', for example), without needing to see the location; * they may need to see long URLs, and be frustrated that the location field is constricted by the presence of the browsing controls in the same line; * they may prefer their browsing controls on the right, rather than the left, of the Location Bar. Therefore, the Command Toolbar and the Location Toolbar should be split into two separate toolbars. These could be horizontally aligned to achieve the current layout, or realigned to achieve any of the layouts described above.
Depends on: 48926
*** Bug 49542 has been marked as a duplicate of this bug. ***
I completely agree, including the dependency on bug 48926.
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Keywords: mozilla1.0, softui, ui
Blocking bug 64073 at Håkan's request -- the separation of these bits of chrome will affect what the location field/URL field/address field is called.
Blocks: 64073
Keywords: ui
Summary: Separate Command Toolbar from Location Toolbar → Separate Toolbar from Address Bar
There are several other prefs that use the text "location bar", and it doesn't look like this bug is going to be fixed right away. I think it would be better to fix bug 64073 now and then go back later and change all of the prefs if the location bar ends up being called something else.
*** Bug 66288 has been marked as a duplicate of this bug. ***
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Blocks: 15144
Every day this bug drives me nuts a little more. --> XP Apps: GUI.
Assignee: mpt → blakeross
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
QA Contact: sairuh → claudius
Ben's the one with the toolbar visions...
Assignee: blake → ben
Blocks: 89350
I would like a review on the chrome changes in this patch.
Keywords: patch, review
I thought you said this didn't work in Modern?
Neil, I applied your patch and fixed some problems with it. I am still hacking on it to make it all work in modern. FYI, having "Home" and "Search" in the toolbar (rather than Personal Toolbar) will be included with this fix (hopefully).
Assignee: ben → hwaara
Comment on attachment 48289 [details] [diff] [review] First go at a patch. Works best in Classic :-) obsoleted. neil and I will be working on a better patch.
Attachment #48289 - Attachment is obsolete: true
Summary: Separate Toolbar from Address Bar → Separate Toolbar from Address Bar [urlbar]
Passing over to Neil.
Assignee: hwaara → neil
Attached patch Updated patch to work in Modern (obsolete) (deleted) — Splinter Review
Attached file Modern home button images (obsolete) (deleted) —
Attached patch Fixed flex and added tooltips (obsolete) (deleted) — Splinter Review
Attachment #51213 - Attachment is obsolete: true
Neil, can you attach a screenshot of how it is supposed to look?
Attached image screenshot (48K) (obsolete) (deleted) —
The tooltip says 'Location Toolbar'. Shouldn't that be 'Location Bar'? IIRC this is what it was in previous versions of Netscape.
I just copied the tooltip from all the other tooltips in Mozilla.
I don't want to be the buh man - I really like the additional horizontal space for the location bar. But isn't that an incredible waste of space? The empty space in the Toolbar really invites people to overload it and destroy the lean design again. Worst thing is that the user has no option to get back to the old (current) layout. Shouldn't we wait with this until we allow users to place toolbars next to each other? (That was my most favorite feature in MSIE4, back then.)
Ben Bucksch wrote: > I don't want to be the buh man - I really like the additional horizontal space > for the location bar. But isn't that an incredible waste of space? On 800x600 it's a useable amount of space. IMHO the current URL is too short. > The empty space in the Toolbar really invites people to overload it and destroy > the lean design again. Silly me - the search button on the right of the URL was turned off.
<rant> When did MPT say that 'Location' should be changed to 'Address'? I don't see any comment to that effect in this bug. And why's it have to be changed anyway? 'Address' is just so IE-like. We may as well start calling 'Bookmarks' 'Favorites' and refer to mail/news 'threads' as 'conversations'. </rant> I know absolutely nothing about coding (rather concerning as I'm doing a Computer Science degree) but I had a look at the patch and noticed the following line: +<!ENTITY personalToolbar.tooltip "Bookmakrs Bar"> As I said, I know nothing about coding but surely that spelling can't be right. And when did it stop being the 'Personal Toolbar' anyway?
this bug depends on a toolbar UI customization spec (that i am working on) before it can be implemented. there are also some significant changes to Modern that will be made in the future to accomodate this bug, as well as accomodate other facets of toolbar customization. since we cannot implement the feature without also breaking modern, or breaking the current UI, i suggest we time this feature with the broader toolbar changes that are coming up. The changes coming up are both customization UI and Modern chrome changes.
This should be fun!
This is a drastic change to the toolbar layout, and as such, it should not happen before Mozilla 1.0.
I agree with Marlon that a change like this shouldn't be made until we have the customization features necessary to allow the user to choose. Neil, what do you think?
Blake, I just wrote a patch, you should be asking mpt.
Blake, Marlon is mistaken in stating that this bug depends on toolbar customization; in fact the reverse is true, because you can't customize the Toolbar if (as is the case now) there is no Toolbar with space available to customize. Every previous version of Mozilla (1.x through 4.x) had toolbar buttons and the address field in different bars, without horizontal toolbar alignment not being customizable; and that is also the case even in the latest versions of iCab and MSIE for Mac (to name two). Marlon also appears to be incorrect in claiming that the patch breaks Modern, as attachment 51851 [details] shows Modern working just fine with the patch applied. Finally, I think it's unreasonable for him to claim that this bug is dependent on his own sekret toolbar customization, when he hasn't CCed himself to the relevant bug (let alone assigned it to himself or shown any signs of working on it), and when the fix for this bug is a major improvement in itself. Hyatt, behind lack of speed, I regard this bug as Mozilla's second biggest usability problem overall (not to mention being the only obvious bug blocking use of Mozilla at the Internet cafe). Obviously you have a large, high-resolution screen (I've seen photos:-), so that the extreme shortness of the address field isn't as aggravating for you as it is for many other advanced users. And people like you and I (and most other Mozilla contributors) have no problem fossicking our way through menus, know how to press Enter after typing an URL, and don't rely on prominent access to things like Home and Search in the main Toolbar (rather than the `Personal' Toolbar which we might have turned off). But for millions of people this is not the case; they prefer to avoid menus if possible, and the lack of basic features such as Home and History in the toolbar is very annoying. I hesitate to say that any lightly-modified distribution of Mozilla 1.0 (such as the equivalent Netscape release) would not be a credible mass-market browser without this bug fixed; but it would be doomed to the same niche audience of extremely technically-inclined users that it has now. And that isn't really what I'm here to achieve.
Blocks: 43739, 48820
Attached patch updated patch for the current trunk (obsolete) (deleted) — Splinter Review
This patch is basically the same as the previous one. I updated it so that it can be applied cleanly to the current trunk. There is one minor bug fix (a missing single quote mark). I also posted a patch for bug 89350 (basically based on this patch). It simply adds a home button to the nav toolbar. The discussions on this bug and bug 89350 are quite inconclusive, so I'm not sure which bug should depend on which (as far as I can see, there are at least four bugs involved: 15144, 48926, 49543, and 89350). Frankly, I don't really care whether the address bar is separated from the nav bar, or whether the toolbars are customizable. But personally I do think a home button on the nav toolbar is really great (especially since I want to get rid of the personal toolbar because of bug 107926). But, of course, I'm not a UI expert, so...
I, for one, would very much like to see this applied to Mozilla soon. This has to be one of my biggest pet peaves. At work, my monitor is set to 1024*768 which is OK for this current toolbar setup because it displays nicely (good resolution). However, at home, I do not have the latest and greatest monitor. Any resolution over 800*600 just shows up poorly, so without getting rid of the go, search, and print buttons(and I would really like to keep at least the go and print around), I cannot make use of a higher resolution to get a longer adressbar. And I don't feel like I need to upgrade any hardware to acomplish this task, as every other browser is just fine in this area. I feel bad for all the people that work in 640*480 because the adressbar is just rather jokey in that res. I know this is an enhancement, however, it really shouldn't have to be. This should've been the way this was designed from the get-go, but it's a little late for should haves and could haves. If this patch works, and works well, I believe this should go in sooner, rather than later (yes, I've heard the talk about this special toolbar custimization stuff but...). Let's apply it to the trunk and see how it behaves. If no problems, fine. Then work can continue normally for all the other "enhancements" to this area. If problems arise, then at least these things can be worked out/on so that when Moz is ready to make it's big release, this will be working properly. Why wait until 0.9.9 or later to land these and then deal with any issues that may pop up. Seems like more headache to do that. Don't get me wrong, I like Mozilla and use it often. However I would probably use it more often if this "enhancement" was in place. Just my opinion(s). Oh yes, and if these toolbars become separated, PLEASE (as also in this bug) add "Home" to the Nav Bar. Thanks.
Please put the home button in the navigation toolbar. If you seperate the location entry box into another toolbar please make it an option. I would love the current setup plus the single addition of the home button to the navigation toolbar. Screen size is precious on a 1024x768 laptop. I do not wish to squander it with the personal toolbar. I don't use booksmarks in any browser. I use my own scripted home page with a google search box and much more. I use the home button extensively in my daily browsing to return to this scripted home page. The great quality of the mozilla mail and news client (IMAP support is very well done) has me switching over to mozilla 100% but the extremely annoying home button location is a major hindrance.
You are a very special case. For almost all other users, bookmarks are much more important than Home. If you created a scripted homepage, then you can hack your Mozilla to have the home button.
what do you think about bug 115118?
Cymen, pressing Alt+Home (or equivalent on non-Windows platforms) will take you home.
[q]You are a very special case. For almost all other users, bookmarks are much more important than Home. If you created a scripted homepage, then you can hack your Mozilla to have the home button.[/q] My scripted home page might make me a special case but I only mentioned that to give an example of why the home button is important to me. Many other people have argued to have the home button on the navigator toolbar. All the other browsers have it, why not at *least* make it an option on Mozilla? A number of arguements for the inclusion of the home button on the navigator toolbar have been made yet every time the response is that "you are special", "this isn't needed", "I don't use the home button so you don't need it", yadda yadda yadda. Why is there such opposition to this relatively simple inclusion? <i>what do you think about bug 115118?</i> Personally I'm not a big fan of floating anything (I'm assuming your note is in reply to mine). I like small, well-crafted, fixed in place (non-floating) user interfaces. Internet Explorer does exceedingly well at providing such an interface - you can use minimal buttons that hide the text display to conserve on screen usage. The end user gets to decide what buttons they want on their toolbar, the button size, whether they have text labels or not, etc. I can live with Mozillas larger buttons but I can't live without my home button. [q]Cymen, pressing Alt+Home (or equivalent on non-Windows platforms) will take you home.[/q] Thanks for pointing out an easy solution but I was aware of this already (it is alt-home on linux too). This doesn't get around the fact that a button would be much more useful. In my case switching between desktops and laptops makes remembering the alt-home finger judo a bit hard (and I do touch type). [q]If you created a scripted homepage, then you can hack your Mozilla to have the home button[/q] I agree. If I didn't think this wasn't an issue that affected more than a few users I wouldn't be here bitching. But I think that the home button is a common feature in web browsing that users have come to expect to have in their browser. I'll get off my ass and figure out how to get my home button in Mozilla. But all those users that can't figure out how to do that will simply remove Mozilla from their machines and go back to using some other shoddy browser. I can't see a rational arguement to exclude the home button. So many uses are obvious... The corporate intranet home page, the scripted netscape.com home page, the internet cafe, etc. So what I'm left wondering is whether the exclusion of a home button is going to continue to be standard procedure or if the marlon bishops work is going to make it an easy choice (even though he too seems to be opposed to the home button). I love Mozilla but please reconsider the exclusion of the home button from the navigation toolbar.
Can we move the Home button- and other tangential discussions to other places, like separate bugs or a newsgroup? I will respond there, then.
For the Home button, it's Bug 89350 "Home button should appear on main Toolbar"
Adding myself to CC, and at the same time, nominating for mozilla1.0 target milestone. http://mpt.phrasewise.com/stories/storyReader$35 There is a patch for this, what is keeping it back ?
I think we need a little more polish on the visual look here. Does the patch still make things look like the screenshot in the bug? If so, the URL bar is ugly and needs to be fixed up.
not just a little more polish. A LOT. modern needs it's "modular Modern" update. and the Toolbar Customization UI spec needs to get implemented, of which this is a dependency.
What dependencies are you talking about Marlon; "modular Modern update", "Toolbar customization", "Toolbar Customization UI spec" -- there is a patch, that works fine, it just needs some cleanup. Then we can check it in and this will work. There is no real dependancy on the stuff you mention. I think it's bad practice to keep adding pseudo-dependencies to most-wanted bugs like this one, unless there are real, very important reasons.
Get the affected parties (module owners, or peers if no owner) to r= the patch, then get an sr=. I just glanced at the patch and spotted a typo (Bookmakrs) that should be fixed first. /be
Where would one find the Toolbar Customization UI spec?
Yeah, I apologize, I added bug 48926 to the wrong field by mistake. As I said in comment 33, we can't have a customizable or horizontally rearrangable toolbar until we have a toolbar with space available to customize or rearrange -- i.e., until this bug is fixed. See 4.x, 3.x, 2.x, 1.x, Opera, and iCab for examples of browsers which have their toolbar and address bar separate without having a customizable toolbar. I've sent Neil and Håkan the list of things which need fixing for the patch to be review-worthy (one of which is the typo Brendan mentioned).
No longer depends on: 48926
Blocks: 48926
1) The images required to make things "re-arrangeable", such as the URL field, are part of an update that has yet to be applied to modern - "modular modern" 2) this bug is about customizing toolbars - the ui for separating toolbars, part of "toolbar customization ui", is presently in draft specificaton phase. which is also presently not identified as a priority - which means it's not going to be implemented very soon. there's a large amount of design work that has been completed, but hasn't yet been published or finalized.
This bug is not about customizing toolbars. This bug is about separating the location field into its own toolbar. Doing so is IMO a requirement *before* we can proceed with toolbar customization. I think this bug is also primarily concerned with what the default setting should be, regardless of whether customization is implemented or not. There have been numerous (again IMO) compelling arguments made for separating the location bar, and it seems like this would be a worthwhile thing to do even without implementing toolbar customization.
->me (working on a patch)
Assignee: neil → hwaara
Attached image Screenshot (deleted) —
Attachment #51214 - Attachment is obsolete: true
Attachment #51847 - Attachment is obsolete: true
Attachment #51851 - Attachment is obsolete: true
Attachment #52494 - Attachment is obsolete: true
Attachment #58335 - Attachment is obsolete: true
Attached image btn1.gif (obsolete) (deleted) —
You need this image in themes/modern/navigator/icons to test the patch.
Attached patch Patch v1 (obsolete) (deleted) — Splinter Review
Fixes a number of problems with the old patches, and a bunch of nits from mpt. Testing appreciated. There is one glitch in Classic and one Modern, that I think should be addressed when this patch is checked in: 1. The Modern "Print" button-icon - we need a new "round" image for this - it looks a little disaligned on the Toolbar right now. 2. The Classic "Home" button's icon - it should be a little bigger than it is.
Mozilla calls uris locations, not addresses.
IMO we should go in the other direction and get new back/forward/reload/stop buttons that actually match the icon style of the other apps. And we should put text back underneath the buttons. :)
> Mozilla calls uris locations, not addresses. There's been a gradual shift from 'Location' to 'Address' in the UI. Pull up the context menu for a link and note how 'Copy Link Location' has become 'Copy Link Address'. Then recall how the traditional Netscape hand cursor was replaced with the system default (read: IE cursor) on Windows. Coincidence? I think not. There's obviously a conspiracy within the Mozilla community to secretly change Mozilla into IE. We'll be calling them 'Favorites' next. Seriously now, I believe the decision was made by MPT who gave some reasons that I seem to remember made reasonable sense. I think there was a newsgroup discussion as well but I may have just been dreaming (yes, I dream about Moz sometimes).
No, there's no agreement or reasonable consensus in favor of changing location to address when the referent is a hyperlink. There have been "accidents", or were they "sneak attacks?" Please stop. Blake, didn't you undo your unintentional change to Copy link location? /be
While I appreciate the hard work going into this patch, I see no comments anywhere indicating that this patch will continue to allow the current behaviour of using the space at the top of my browser window optimally. I'm not a typical user, I'll be the first to admit: I have thousands of horizontal pixels to play with, but only a few hundred horizontal ones. My typical browser window is 1600x600 pixels. I already have a menu bar, a navigation bar, a personal toolbar, a link toolbar, a tab bar and status bar. Please _please_ don't add yet another horizontal bar unless you are going to make it possible to place that horizontal bar into the newly created gap. If you need to add horizontal room for other people, make it possible to remove the "Stop" and "Print" buttons and the throbber -- I never use those. But please don't make my browser window even shorter. BTW I also don't understand why the Home button needs to be moved. It's a link, it belongs with all the other links on my personal toolbar. Again, if you are going to move it, please make it possible to leave the current UI as is.
This is a first step in the direction of customizable toolbars, but you can't get everything you want at once. Please, this is one of many patches (hopefully) that will gradually improve the toolbar support we have. This bug is for splitting the toolbar, not for making them customizable. That's bug 15144. Regarding "Address": I thought this had been agreed upon in other bugs and in the newsgroups? If there is a strong demand to change back to the old "Location" and "URL" semantics, I can do that as well.
I agree with Dave that Modern should use standalone icons inside visible rectangular buttons, since that would make their apparent target area much larger (especially for the Back and Forward menus), and it would allow you to use the shapes of the icons to distinguish them (it's hard to do that now because the circles are more vivid than the icons themselves). But that can be done after this patch lands ... Håkan, you can find full-size Home icons for Classic in all states here: <http://mozilla.org/docs/refList/user-interface/visual/buttons/winimage.html> <http://mozilla.org/docs/refList/user-interface/visual/buttons/macimage.html>
Håkan: Like in real estate, it is "Location, Location, Location".
Attached image home.gif (obsolete) (deleted) —
New home.gif for the Classic theme
Attached image home-active.gif (obsolete) (deleted) —
New home-active.gif
Attached image home-hover.gif (obsolete) (deleted) —
New home-hover.gif
Attached patch Patch v2 (deleted) — Splinter Review
New patch. Changes: fix home button in Classic, and change "Address Bar" to "Location Bar" as discussed.
Attachment #64764 - Attachment is obsolete: true
Comment on attachment 64826 [details] home-hover.gif Hmm... shouldn't we be using -moz-image-region on these images these days?
While we're discussing wording... the Personal Toolbar now seems be the Bookmarks Bar. Which is it to be? Personally I like Bookmarks Bar better.
Let's not go around changing terminology while implementing this patch. That's just going to make it even more contentious than it already is. Please retain current terminology, i.e., "Location" as well as "Personal Toolbar". Those sorts of wording changes should be the subject of separate bugs.
hwaara: This might be "one of many patches (hopefully) that will gradually improve the toolbar support we have", but if one of the steps along the way reduces our usability or increases the pixel footprint of our chrome, then there is the distinct chance that it will end up in a released product in that state, not to mention it will be used by people using nightlies and cvs tip. IMHO this kind of work should happen on a branch until it is ready to be committed all at once. The immediate benefits of splitting the toolbars are, in my opinion, completely outweighed by the disadvantages of an extra 20 pixels of chrome footprint. This is especially important if the work is only "hopefully" going to be done, as you put it.
I completely agree with Ian about creating a branch. I don't want my toolbars changing daily, as I have to use the nightlies to get work done. I also don't want more toolbar than content space, so if this goes in without anyway to revert to the current design, I'll have to hunt you down. mmmmmkay.
Hmmm. Perhaps we need to implement toolbar customization first, including the fixing of the buttons in Navigator, the implementation of modes (text/pictures/etc.), and the ability to put all of the toolbar objects on any toolbar.
hmmm, if there's one idea i like, it is that one.
marlon bishop wrote: > hmmm, if there's one idea i like, it is that one. So where's the spec?
Please, this 'enhancement' has been hanging around for what? Almost a year and a half? IMO, the separated location bar should've been separated from the beginning, just like every other browser, previous version of Netscape, etc. On the browser UI side, it's probably my most major annoyance. I'm trying to save space myself too - wasted space. I've never really used the personal toolbar from 4.x and don't now. The only reason it's up is for the silly home button that's not on the Nav bar. I'd gladly hide the personal toolbar for a separated location bar and home button. Of course I'd have still have the same amount of toolbars, however, they would all be functional and not just sitting there looking pretty. I do understand those that want the option (if separated) to revert back to everything on the Nav bar, and don't disagree with them. I just think that since there is actually a working patch now that looks good, I don't see waiting another 6 months or year to implement it. Gotta start somewhere. Just my .02
If I may make a comment on the spec. It's great except for one thing: Don't lose the grippies. MSIE (and many other Windows programs) use them for rearranging toolbars. In fact, one of the first things I tried with Mozilla (after reading about the 'great customization' it offers) was to drag the toolbars via the grippies. If Moz has the ability to move toolbars, then the grippies should stay. If toolbars are immoble, then the grippies should go. my $0.02
mpt: I agree with djk. Moving toolbars needs more discoverability. Either a menu item (like in Gnome), or grippies, or a tooltip... just _something_ to inform power users that moving toolbars is possible. marlon: Rumours are that you have also written a spec. Could you please publish it so that it can be compared to mpt's? marlon and mpt: It is a pity you did not work on these specs together (either in pixeljockeys, n.p.m.ui, or, at a pinch, by e-mail). Mozilla's QA people work as a team, Mozilla's engineers work as a team, Mozilla's evangelists work as a team. Yet repeatedly we end up with two conflicting views for UI specs with the parties not cooperating. staff@mozilla.org: Do we have a process in place yet for resolving the conflicts that are bound to happen as soon as someone tries to implement one of these specs? We've been waiting for YEARS now for some sort of UI process to be determined. It would be very unfortunate if this continued lack of process resulted in the different parties doing their own UI instead of contributing and working together on one UI.
Attached patch My take (obsolete) (deleted) — Splinter Review
Slightly different in that it doesn't change existing ids, and thus leaves more things alone. I'm also not sure about removing the prefs for the existing buttons before we have something to replace them with.
> Slightly different in that it doesn't change existing ids, and thus leaves more > things alone. Hmm, doesn't leave the wording alone... (comment 70).
->hyatt
Assignee: hwaara → hyatt
Are we any closer to seeing this "enhancement" fixed? Or any closer to seeing the toolbar customization spec implemented? Moz 1.0 is getting closer and closer and it would be a BIG disappointment to not have this functionality by then, or at least this bug working.
Okay everyone seems to be thinking about using this as a stepping stone to bug 15144. Aint we forgeting something? The major problem I see is if this doesn't get fixed by 1.0 every skins made will be based on current layout and they won't be very happy. If we don't fix this by 1.0 it shouldn't be fixed until 2.0 or something, the benefit of stable api (that apply to skin makers too) in 1.0 would be meaningless if they have to make a new skin for mozilla 1.1 Just get the essentual infrastructure in place, and then in bug 15144 spec out the customisation standard (shortcut button size etc). The usability issues are already discussed by mpt and others and everyone seem to agree with the reasoning behind it, so I wont go into that.
Attached image modern skin icons per toolbar arrangement spec (obsolete) (deleted) —
Is this going to happen pre-1.0? I agree with Mr. Lee that it will be annoying to skin makers to have their skin set for 1.0 then have this obsoleted. This irks skinmakers and is why we don't have any skins but classic and modern at the moment, as you probably know.
The history icon in that is a little IE-esque... but otherwise it looks nice. :-)
I agree. Other than the history icon, all look fine.
The history icon looks more like a Pac-Man than anything else. I had to take a look at the spec to figure out that it is the history icon. It's completely unintelligible. Also, why is there a print button? mpt's spec doesn't mention one.
Did Netscape 4 have a History icon somewhere? If so, what did it look like? (Opera doesn't seem to have a History icon anywhere). I took a brief look at the toolbar icons on Tasman (IE 5.x for Mac OS) and liked them. Had no time to take a screenshot though.
NN4.x hasn't any icon or button for history.
I would like a skin with a big back-button on the left side and a big one on the right. Really. If I'm correct, this isn't possible with the current toolbar-structure. Or am I asking too much?
*** Bug 134781 has been marked as a duplicate of this bug. ***
adding self to cc list
Ian, please do not spam bug reports with "cc'ing myself". While adding yourself to cc list doesn't send mail to most of us (this feature can be activate through bugzilla personal prefs), your comment IS sent while doesn't offer any useful info to this bug.
<completely offtopic> > Ian, please do not spam bug reports with "cc'ing myself". He had to. Due to a bug in Bugzilla, you have to add a comment when adding yourself to the CC list on several bugs at one time. That bug has already been fixed, bugzilla.mozilla.org just hasn't updated it's Bugzilla installation yet. </completely offtopic>
For a NS4.x-style history icon, see http://home.netscape.com/browsers/future/aurora.html
Sorry to add useless comments, but will this make it for 1.0? This is my biggest pet peeve besides bug 79992, and 1.0 is really close.
http://bugzilla.mozilla.org/attachment.cgi?id=65067&action=view#rearrange Related bugs: bug 7696 - Floating Toolbars bug 47418 - Dockable/Undockable/Closable sidebars bug 45532 - Context menu for toolbars bug 48926 - Horizontally adjacent toolbars By reading that toolbar spec, it appears that this bug should depend on all of the aforementioned.
Toolbars should still be collapsable even if there is a toolbox. For the whole toolbox row to collapse, all the toolbars on the same row would have to be collapsed.
Obviously, we're not going to see the implementation of the new toolbar spec in version 1.0. But we can't wait until 2.0! This _is_ a very important feature, and I'm surprised it wasn't implemented when first creating the toolbar. This is the bible: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65067 Go for it!!
Re: Comment #88 From Christian Biesinger 2002-03-17 01:45 > The history icon looks more like a Pac-Man than anything else. Suggesting a variation of this icon http://images.google.com/images?q=tbn:0MysHGE50k8C:www.essentialmac.com/images/icon_myst.gif as base for a new history icon. > Also, why is there a print button? mpt's spec doesn't mention one. mpt mentioned several off-by-default toolbar buttons though, including a print button: <mpt> Oh yes, there are lots of buttons that would be off by default <mpt> Print, Save, Zoom, Encoding, Style, Preferences, New Window ... These, of course, also need icons.
*** Bug 153135 has been marked as a duplicate of this bug. ***
I loved the spec (attachment 65067 [details]), mpt :) However, I do agree with Hixie and djk in comment #78 and #79. Come on people, something must be done here. This is a 'basic' feature that people expect to exist. It was one of the first things I tried when I installed Mozilla.. I agree with Hixie in comment #79, Mozilla and Netscapes UI 'teams' really need to work together. Lets face it, Mozilla's UI is bad. My mother wouldn't understand 20% of it, and as someone else said, she would _not_ find out how to send emails, which is a severe issue. I think there is an conflict of interrest here.. but there should not be at all! The interrest of both UI 'teams' is ofcourse to make the UI easily understandable. I would have to say that I find mpt's spec very good. Not just this one, but all the things he has said while I have been hanging around here.. He does not only say /how/ it should be (like Netscapes UI group), but also states (and clarifies) /why/ it should be implemented as he has designed it. I'm sorry if that offended some of you, but that's the impression I've got at this time. What about adapting Apple's design procedures ? I think it goes something like: 'If the code touches /any/ UI code _at all_, it has to be clarified with the UI group before checkin.'. That means that all UI code for Mozilla would have to be clarified by the 'Mozilla UI' module-people first. 'Mozilla UI' needs to be created as a module, see http://www.mozilla.org/owners.html I don't think it will help any, but the following keywords should be added to this bug: access - because I want to customize the toolbars to my special needs. helpwanted - because something has to happen here. highrisk - because it touches many parts of the code, and introduces lots of new code. will cause some bugs. intl - because people will need to update their translations. qawanted - because we need some QA here to sort things out (that means, cooperation between Netscape and Mozilla UI people). relnote - this feature is _very_ important for (I would like to say /all/) many people, and could be a reason for them to upgrade. ui - that's what it's all about :) And while you're at it, remove the mozilla1.0 keyword.. Someone told me Mozilla 1.0 had shipped ;) Well.. that's just my 2 NKR.
I agree, the Navigator UI needs to be changed ASAP. The problem is that toolbar customization is something many people want landed before this bug is put into high gear. Plus, the chevron thing for the menu overflows is needed to make the changes successful. Also mpt and others have yet to have seen a good icon set for the toolbar. Check this out: http://groups.google.com/groups?selm=3D029DF6.E3C15D9%40myrealbox.com BTW: someone with the access should update the keywords and get this thing on the radar for a not so distance release (probably not 1.1).
Check out these icons (linked from mpt's site): http://www20.brinkster.com/rochette/moztoolbar/ They look nice both in classic and modern. Check them out.
Blocks: 154772
Is it possible for someone with access to update the keywords on this, and change the priority and/or severity? C'mon, this is important!! We are already passed mozilla 1.0, this needs to be updated immediately! Can anyone else provide a status update on this? Is implementation planned soon? Or is this just floating around in space??
------- Additional Comment #107 From Mike Palumbo 2002-07-09 09:18 ------- > Is it possible for someone with access to update the keywords on this, mozilla1.0 should be removed, indeed. I think mozilla2.0 or perhaps 1.5 is a more likely target. > and change the priority and/or severity? Not seeing anything wrong with them. > C'mon, this is important!! We are already > passed mozilla 1.0, this needs to be updated immediately! Not seeing any urgency in updating the information. Additionally, I myself don't have the privileges to do that. > Can anyone else provide a status update on this? I'm working on an own implementation in my spare time, but it seems like a long and boring task. I also can't do all stuff mentioned in the spec, including customization. What I can do is rearrange the chrome etc. to create a better default chrome. I'm several steps further than http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view and the other screenshot: Other buttons such as "History" and "Mail" have been added, and the components bar has been removed (in all components available in default builds; that excludes calendar etc.). But the whole thing still looks incomplete for me, and as said, customization is still not really possible. > Is implementation planned soon? Or is this just floating around in space?? Call me pessimistic, but I think this won't be resolved before at least late 2002. There's several patches in this bug, and while I haven't tested them, others apparently haven't either (at least not thoroughly, as there is no *reviewed* patch), so I'm feeling lack of interest by the developers.
> and change the priority and/or severity This /is/ an enhancement request (albeit an important one), so severity is correct. Priority, like target milestone, is for the assignee only.
Keywords: mozilla1.0
>This /is/ an enhancement request (albeit an important one), so severity is correct. I guess it all depends on your viewpoint. I personally don't see this as an enhancement, but as a major usability impediment that is blocking several bugs. I can't tell you how many people have asked how to put the location toolbar on its own line, like they are used to having it under IE or Opera. To me, this is a major *problem*, not just an enhancement, and it is holding Mozilla back *severly*. Perhaps I just see this as much more important than other people do??
Mike, please take your questions to the newsgroups. With every comment we make, we are spamming a CC list of 65 people (sorry).
Well, maybe if someone actually allowed this "enhancement" (BUG) to be fixed, than nobody would get spammed.
>But the whole thing still looks incomplete for me, and as said, customization is still not really possible. Would you mind posting what you have complete, so that we can look at it? Or at least a screenshot anyway? <g> As for customization, read the spec that mpt posted, under the "Implementation Plan" section: "1. The Toolbar and Address Bar should be split, and the Personal Toolbar renamed to the Bookmarks Bar. This step can and should be done before other changes to toolbar structure or customization, as it provides a significant usability improvement in itself." It doesn't matter if we can't completely customize the toolbars yet, we should at least split up the address bar from the rest of the toolbar. It's an important start to getting some real usability in the Moz toolbars. >Mike, please take your questions to the newsgroups. Wasn't really any questions, but I will say that I am hesitant to take anything to the newsgroups; as soon as I do that, it's one step closer to this bug falling off the radar again. This bug has been open for almost 2 years now, its OLD, it's blocking other usability bugs, it needs to be fixed. Also, I will apologize for the emails everyone received (Id hardly call it spam though, its definitely not UCE). So my question now is, what can I do to help with this? I want to see this bug marked as Fixed. The patches obviously need to be tested, but is there still more Chrome work to do? That I can help with. I'm interested to see what Chucker has done on this.
> Also, I will apologize for the emails everyone received (Id hardly call it spam > though, its definitely not UCE). The term 'spam' is generally used to refer to any Bugzilla mailings that do not help to get the bug fixed. Such as this one.
No offence, but the screenshot (from January!) in comment #53 looks pretty fixed to me
>No offence, but the screenshot (from January!) in comment #53 looks pretty fixed to me Agreed, it most certainly does. Is it just that no devs tested the patch, or is something else holding this back??
Re: Additional Comment #112 From Tobias Tinkerman 2002-07-11 07:27 ------- > Well, maybe if someone actually allowed this "enhancement" (BUG) to be fixed, > than nobody would get spammed. Well, if you could contribute to fixing this in one way or another, your comment wouldn't be *considered* spam. If not, then patience is a virtue, as they say. We all want this fixed, but that alone won't help. ------- Additional Comment #113 From Mike Palumbo 2002-07-11 08:47 ------- > Would you mind posting what you have complete, so that we can look at it? Or > at least a screenshot anyway? <g> As to a patch, no, because 1) I'm not that familiar with using diff and patch yet and 2) I don't see any point in offering a patch that is known to cause other regressions (such as currently, the loss of ability to remove the print button in the navigator preferences as I'm working on that at the moment). As to a screenshot, sure, why not :-) Created this one for your viewing pleasure: http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png As this is sure to get criticized, let me note several things first: 1. yes, this is based off the icons from this attachment: http://bugzilla.mozilla.org/attachment.cgi?id=74549&action=view , which aren't perfect yet (see comments from biesi etc.) 2. no, the print button does not belong there for the default setup, as per mpt's spec. it's just enabled because I could only disable it by manually editing prefs.js at the moment and I was too lazy to do that for the shot. 3. yes, I've seen too that the shading between address bar and personal toolbar somewhat isn't right, and I'm looking into that. 4. There's a strange problem with the bookmarks, search and history buttons causing the sidebar sometimes not to open 5. The Go button is ugly, I know. It always was. > As for customization, read the spec that mpt posted, under the "Implementation > Plan" section: > "1. The Toolbar and Address Bar should be split, This is done. > and the Personal Toolbar renamed to the Bookmarks Bar. This is not yet done. > This step can and should be done before other changes to toolbar structure or > customization, as it provides a significant usability improvement in itself." Okay, but I might be able to do the customization stuff too. I myself would prefer a complete solution. > It doesn't matter if we can't completely customize the toolbars yet, we should > at least split up the address bar from the rest of the toolbar. It's an > important start to getting some real usability in the Moz toolbars. Maybe. > Wasn't really any questions, but I will say that I am hesitant to take anything > to the newsgroups; as soon as I do that, it's one step closer to this bug > falling off the radar again. For whom? I think the problem is that those who most want it fixed are also those who least can fix it themselves. And vice versa. > So my question now is, what can I do to help with this? Are you good at graphics? Provide us with better new toolbar items. Not to put the circle around them would be a good start, according to mpt. > The patches obviously need to be tested, I haven't looked at the patches yet. If I were to test them on my own build, I would break my own changes ;-) > but is there still more Chrome work to do? That I can help with. I'm > interested to see what Chucker has done on this. See above. (Additionally, I've removed the components bar, and other less interesting stuff) Re: Additional Comment #115 From Tobias Tinkerman 2002-07-11 09:16 ------- > No offence, but the screenshot (from January!) in comment #53 looks pretty > fixed to me It's a good start.
>As to a patch, no, because 1) I'm not that familiar with using diff and patch >yet and 2) I don't see any point in offering a patch that is known to cause >other regressions (such as currently, the loss of ability to remove the print >button in the navigator preferences as I'm working on that at the moment). Gotcha, didn't know there were regressions happening. >http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png Looks great overall! >> As for customization, read the spec that mpt posted, under the "Implementation >> Plan" section: >> "1. The Toolbar and Address Bar should be split, >This is done. Then why isn't this bug marked as fixed?? This bug is only for splitting up the Address Bar from the Toolbar, which has been done. >> and the Personal Toolbar renamed to the Bookmarks Bar. >This is not yet done. This is Bug #48820. >Okay, but I might be able to do the customization stuff too. I myself would >prefer a complete solution. Yes, as would I, but that is beyond the scope of this bug. Not that it shouldn't be solved, but it seems like you are trying to fix this and bug #15144 at the same time??? I suppose if you can do it, more power to you, I've always been one for taking things one step at a time though. >For whom? I think the problem is that those who most want it fixed are also >those who least can fix it themselves. And vice versa. Probably because this affects the "average users" much more than the programmers. >Are you good at graphics? Provide us with better new toolbar items. Not to put >the circle around them would be a good start, according to mpt. I'll see what I can do, sure. Should I also try redesigning that hideous "Go" button? :) >> No offence, but the screenshot (from January!) in comment #53 looks pretty >> fixed to me >It's a good start. For this bug alone, it's a solution. For the overall toolbar problem, it is a good start. I think we have enough here to test and at least mark this bug alone as complete. I see no reason why we shouldn't do that, then move onto the other customization/toolbar bugs? Please correct me if I'm wrong.
Re: Additional Comment #118 From Mike Palumbo 2002-07-11 11:08 ------- > >http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png > Looks great overall! Thanks. >>> "1. The Toolbar and Address Bar should be split, >>This is done. >Then why isn't this bug marked as fixed?? Don't ask me; ask others. I haven't looked at the other patches, as said. Maybe they're doing exactly what they should do. > This bug is only for splitting up the > Address Bar from the Toolbar, which has been done. Well, mpt put his spec in *here*, so it appears there is more to this bug in his opinion. >>> and the Personal Toolbar renamed to the Bookmarks Bar. >>This is not yet done. >This is Bug #48820. Oh. You're right. > Yes, as would I, but that is beyond the scope of this bug. Not that it > shouldn't be solved, but it seems like you are trying to fix this and bug > #15144 at the same time??? Precisely, I'm trying to implement mpt's spec. Which maybe shouldn't be in this bug, but in a tracking bug. > I suppose if you can do it, more power to you, I've always > been one for taking things one step at a time though. See above :-) > Probably because this affects the "average users" much more than the > programmers. Yeah. And that's the reason why this isn't fixed yet. > I'll see what I can do, sure. Should I also try redesigning that hideous "Go" > button? :) Sure. That shouldn't be too difficult. If you need advice, ask for it at the n.p.m.ui newsgroup. > For this bug alone, it's a solution. Indeed. > I think we have enough here to test and at least mark this bug alone as > complete. I see no reason why we shouldn't do that, then move onto the other > customization/toolbar bugs? Please correct me if I'm wrong. I'd be fine with that, assuming that the patch we'll be using causes no regressions (it shouldn't be that difficult to write such a patch ;-) ).
To quote from MPT's original report: "the Command Toolbar and the Location Toolbar should be split into two separate toolbars." I think a fix that achieves that should close out this bug. All other customizations, changes, etc. that are not absolutely required to implement this change, while important, should be addressed in their respective bugs or spun-off into new bugs, if none exist. One of my pet peeves is the mega, morphing bugs that seem to takeover "simple" requests.
Okay. I've just read through this bug. There's a lot of discussion about things in addition to the original point of the bug. As far as I can tell, Mike is right in stating that this bug is ONLY about separating the toolbar from the address bar. It's not about customizing toolbars, not about moving toolbars, not about having multiple toolbars on the same horizontal level, nor is it about changing the icons on the existing combined toolbar / address bar. Yet it seems to have become a hot spot for debate on these very topics which is morphing the bug into something that it's not, never was, and never should be - and all of this is only causing unecessary delay and frustration. I see that this bug is marked as blocking 7 other bugs - but is not itself marked as depending on anything else that still needs to be done. The fix for this should be simple - then the other ideas can be discussed in other bugs. If there already is a patch that effects the simple toolbar / address bar split then it should be reviewed. Why hasn't this happened?
<q class="ot">A bug is marked fixed when a patch for the bug has been committed to CVS on the specific branch used by the product. for Mozilla Seamonkey (for lack of a better descriptor), that branch is HEAD. No patch attached to this bug has been reviewed, or super reviewed, let alone committed to any cvs branch. As such, this bug is not fixed. If anyone has questions about the life-cycle of a bug that are not answered by the life-cycle of a bug page, please visit irc.mozilla.org #mozillazine and ask for more information. This bug should be focussed on development work, not learning how to use bugzilla.</q>... hyatt isn't working on this bug, if someone is interested in being listed as the assignee they can either take the bug themselves or ask in #mozillazine for someone to reassign it to them.
Assignee: hyatt → nobody
>If there already is a patch that effects the simple toolbar / address bar split then it should be reviewed. Why hasn't this happened? This is exactly what I want to know. I realize that the bug can't simply be marked as fixed yet because it hasn't been reviewed; I think we all realize that. The real question here is why have none of the patches been reviewed yet? We should probably get this reassigned. Hell, I'll even take it if nobody on the Mozilla team is going to (heh, can I do that?!). I want to see this solved! We need to get the patches reviewed, forgive my ignorance here, but what do we need to do to get that to happen? Also, should we make a tracking bug for the toolbar, since it seems like there is a lot of discussion on the subject?
> Hell, I'll even take it if nobody on the Mozilla team > is going to (heh, can I do that?!) I'm not sure. You could put your name in the field and see what happens. <grin> Theoretically, I also have the rights to change field information so I could assign it to you if you can't assign it to yourself - but I don't how appropriate that would be. So far I've only seen bugs assigned to people that are part of the actual Mozilla team, and I don't know if just anybody can walk up and claim a bug or not. > should we make a tracking bug for the toolbar Bug 126321 tracks toolbar customization.
Re: Additional Comment #120 From amutch@tln.lib.mi.us 2002-07-11 11:34 ------- > >To quote from MPT's original report: > >"the Command Toolbar and the Location Toolbar should be split into two >separate toolbars." > >I think a fix that achieves that should close out this bug. And I don't, because of the following. If we were to fix bugzilla as seen here: http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view or here: http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view , we would leave Navigator with lots of wasted chrome space; probably for months seeing how "fast" the other related bugs are processing. >One of my pet peeves is the mega, >morphing bugs that seem to takeover "simple" requests. And one of *my* pet peeves is the problem that causes them: that Mozilla is still flawed in many areas. If we fix this and at least bug 15144 few weeks later, that's fine. But it's not going to happen. Re: Additional Comment #121 From Jason Bassford 2002-07-11 11:41 ------- > Okay. I've just read through this bug. There's a lot of discussion about > things in addition to the original point of the bug. As far as I can tell, > Mike is right in stating that this bug is ONLY about separating the toolbar > from the address bar. Yes, of course it is (the summary is clear enough). My point is that doing so would leave navigator's chrome more broken than it is at the moment, because we would leave more space for the address bar, but waste lots of space with a toolbar with only five (!) buttons. > It's not about customizing toolbars, not about moving toolbars, not about > having multiple toolbars on the same horizontal level, nor is it about changing > the icons on the existing combined toolbar / address bar. True. > Yet it seems to have become a hot spot for debate on these very topics which is > morphing the bug into something that it's not, never was, and never should be - > and all of this is only causing unecessary delay and frustration. I joined this bug quite late, so this problem wasn't caused by me. One thing that possibly confused many - including perhaps me - might be the spec from mpt that's in *this* bug and says "Spec for toolbar arrangement and customization" (!). Re: Additional Comment #123 From Mike Palumbo 2002-07-11 12:14 ------- > Hell, I'll even take it if nobody on > the Mozilla team is going to (heh, can I do that?!). Dunno if you have the permissions (check yourself in your preferences), but I do have them, so I can reassign the bug to you if you really want to try and fix it. > We need to get the patches reviewed, forgive my ignorance here, but what do we > need to do to get that to happen? See timeless's comment; this is quite clearly described in the "lifecycle of a bug" documents. > Also, should we make a tracking bug for the > toolbar, since it seems like there is a lot of discussion on the subject? I think this has turned into it, though nobody wanted it to (except perhaps mpt - was there any special reason behind attaching the spec *here*?). Re: Additional Comment #124 From Jason Bassford 2002-07-11 12:29 ------- > Bug 126321 tracks toolbar customization. Well... it appears to be a dead bug though, and it doesn't depend on this one.
Comment on attachment 66757 [details] [diff] [review] My take on reviews please read comment 47 on potential specs mpt posted one in comment 77 (attachment 65067 [details]) and marlon never mentioned a url for his here. on what this bug is please read comment 51 on changing text comment 59 trumps, however anyone who objects is also welcome to read comment 70 and of course comment 47 Given the preceding, i'm marking the current patch as needs-work. Simply put: module owner and the mozilla.org lead have explicitly stated that this bug is not the place to change text.
Attachment #66757 - Flags: needs-work+
>I don't, because of the following. If we were to fix bugzilla as seen here: >http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view or here: >http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view , we would leave >Navigator with lots of wasted chrome space; probably for months seeing how >"fast" the other related bugs are processing. BIG WHOOP. Look at IE, same scenario the only two extra buttons: autofill and mail. Let's do it and put a button for autofill and a button to launch the mail client. >and one of *my* pet peeves is the problem that causes them: that Mozilla is >still flawed in many areas. If we fix this and at least bug 15144 few weeks >later, that's fine. But it's not going to happen. You acknowledge that megabugs don't ever go anywhere but you want to create a megabug out of this by adding 15144? You obviously don't believe, then, that this is fixable. Maybe just maybe if we LEAVE the extra space it will put the HEAT on to DO the other bugs if everyone else is as peeved about the extra space as you are.
This can't land until toolbar customization is checked in. You're playing with a much larger beast here than I think you realize. Just changing the chrome structure of navigator is the wrong way to resolve this bug. The proper way to fix this is to actually implement toolbar customization, which will allow the user to set their toolbars how they like, ala IE. Just changing the way the chrome is hardcoded fixes nothing other than a few users pet peeves.
Good - better discussion. If the toolbar/address bar is split we'll end up with a toolbar that has some whitespace. I personally feel that this should not be the reason for holding things up. A personal toolbar can have as few as one button, if you've customized it that way, and I don't see anybody complaining about whitespace problems there. (I'm sure that there ARE some people with very few buttons in their personal toolbar - even the screenshots for these patches show such personal toolbars with whitespace.) The navigation toolbar would be in a similar situation. It may not look quite right to some, but that can be easily correct later on with the addition of a few more buttons - to be discussed in another bug. (Having it in people's faces may even make a fix for that particular problem appear sooner than it ever would if the issue weren't forced.)
> This can't land until toolbar customization is checked in. I don't see this bug being blocked by that one. I also don't agree with the statement in principle. (It's sort of like saying that at some point in the future we'll have voice activated, artificially intelligent computers - so why both manufacturing what will become out of date computers at present?) There have been other toolbar changes introduced, none of which have had to wait for customization to happen. Sure, when customization DOES happen, having it will tend to invalidate several of the toolbar changes prior to it (because they won't matter anymore) but I don't see that being a problem. In the interim, we can at least get *some* things working better, rather than not any advancement at all.
> In the interim, we can at least get *some* things working better That's your view, which is why this has to wait. I, along with more people than you think, like the current layout, and have no need for any of the other buttons you propose adding. Going back to the way 4.x works is not an improvement, in my eyes, or appearently in any of the real stakeholder's eyes. >------- Additional Comment #31 From Blake Ross 2001-10-09 19:03 ------- > >I agree with Marlon that a change like this shouldn't be made until we have the >customization features necessary to allow the user to choose. Neil, what do you >think? The attached patch is not the correct fix, just a bandaid for those of you who like a seperate address bar. Once again, the correct fix is to be able to customize the toolbar to your liking, not checking a hard coded version of how you like it to look.
> I, along with more people than you think, like the current layout The reverse is also true. > no need for any of the other buttons you propose adding I've never proposed adding other buttons as a proposed solution to this specific bug. Arguing about your personal opinions on this bug at this point is pointless. All the arguments have been made - on both sides. There are as many people who want to see this as those who don't. For every comment you can quote to me, I can quote one back to you. That's not productive. In the end, if nobody will review a proposed patch and/or drivers won't allow it to be checked in then that will be what kills it. If you want to continue to argue against this bug in principle, you should take it the newsgroups. Posts here should be constructive and/or address *technical* issues.
> This can't land until toolbar customization is checked in. Yeah....well suppose you give us an update or some status of where toolbar customization is at this point. As far as I'm concerned, it's nowhere. Marlon had said in a bug, months and months ago, that he was halfway through a spec. In another bug it was stated that toolbar customizaition was "just around the corner". That corner was probably roughly a year ago. If it's only a few months away than fine. However I have a feeling that it's nowhere near that time frame. It would go a long way to help people, and bugs, that keep getting told wait for toolbar customization if they knew some kind of milestone or year or sometime when this might become a reality. > In the interim, we can at least get *some* things working better, rather than not any advancement at all. Exactly.
> The attached patch is not the correct fix, just a bandaid for those of you who like a seperate address bar WRONG. It IS the correct fix for this bug, which is about separating the Nav bar and Adress bar.
Re: Additional Comment #133 From Tobias Tinkerman 2002-07-11 14:08 ------- > > In the interim, we can at least get *some* things working better, rather than > > not any advancement at all. > Exactly. No, not quite. I can see kerz's point: If we were to implement this, we would end up with a toolbar with 5 or 6 (dependant on whether Home *will* be moved with the patch or not) buttons and an additional toolbar with the urlbar and an optional Go button (and, dependant on the patch, maybe a Search button as well) on it. Those who like the current layout though - which is a single toolbar with (except possibly Home) no less buttons, but way less space used, but then again less space available for the urlbar part - will suffer. So to implement this wouldn't be a win for everyone. Re: Additional Comment #134 From Tobias Tinkerman 2002-07-11 14:29 ------- > > The attached patch is not the correct fix, just a bandaid for those of you > > who like a seperate address bar > WRONG. It IS the correct fix for this bug, which is about separating the Nav > bar and Adress bar. I suppose this bug is invalid or wontfix or whatever then.
> I suppose this bug is invalid or wontfix or whatever then. Only if that's what the module owner or drivers marks it as. Until that time, further discussion should be about how to best implement a patch.
Actually there are two other alternatives, and I'll mention them even though I know the UI people would probably have a problem with it with at least the first one. Keep the existing combined toolbar, but also implement a Navigation bar and a an Address bar. Make the default to show the Nav/Address bar, but also have the possibility of hiding it and making visible the other two separately. That way those who like it as it is are happy, and those who want the two separate are also happy. The other alternative is, if the module owner or drivers would be amenable to doing this rather than simply marking it WONTFIX if that would be their decision otherwise, is to make this bug dependant on bug 48926. Work can continue on this patch until in parallel with any work that might be happening on bug 48926. As soon as that bug is checked in, then the patch for this one could be checked in. What this would mean is that the Nav/Address bar IS split in two, but there would be the option for those who want it of having them joined horizontally and appearing to be the same as is current. (While those who want one under the other would also get their way.) Currently that bug is dependant on this one. That dependancy would have to be reversed. (I.e. We're not separating anything unless we know that we have the ability to put the two pieces side by side...) However, as I say, a large part of the decision process will be based on what the module owner / drivers has to say on this subject. Who *IS* the module owner here? Is it whoever's "in charge" of XP Apps: GUI Features? I think we really need some kind of authoritative answer - and hopefully there's just one voice that will be able to speak up.
> Marlon had said in a bug, months and months ago, that he was halfway through a > spec. In another bug it was stated that toolbar customizaition was "just around > the corner". That corner was probably roughly a year ago. If it's only a few > months away than fine. However I have a feeling that it's nowhere near that > time frame. According to bug 22056 comment 100, Marlon stopped working on the spec because the bossy people kept bothering him.
------- Additional Comment #136 From Jason Bassford 2002-07-11 16:51 ------- > Keep the existing combined toolbar, but also implement a Navigation bar and a > an Address bar. Make the default to show the Nav/Address bar, but also have > the possibility of hiding it and making visible the other two separately. That > way those who like it as it is are happy, and those who want the two separate > are also happy. Sounds messy. Don't like that. > The other alternative is [to reverse dependency with bug 48926 and fix that one > first, then allow address bar within toolbar] Yeah, that's better. > However, as I say, a large part of the decision process will be based on what > the module owner / drivers has to say on this subject. Who *IS* the module > owner here? I thought it's marlon, but I might be wrong. I just noticed this is assigned to nobody. I thought it was assigned to Neil or marlon. Strange.
> According to bug 22056 comment 100, Marlon stopped working > on the spec because the bossy people kept bothering him. In which case, we shouldn't be sitting back and waiting for a nebulous, undefined fix that may or may not be checked in. We should assume that it won't be happening any time soon and proceed with what we can.
> I just noticed this is assigned to nobody. I thought it > was assigned to Neil or marlon. Strange. It was assigned to Hyatt - until Timeless reassigned it to nobody, around the time of his strangely formatted comment 122. He said that Hyatt was no longer working on it. (This is reminiscent of bug 22056 comment 101.) But even if it's now assigned to nobody - Marlon is the module owner? >> [to reverse dependency with bug 48926 and fix that one first > Yeah, that's better. Unfortunately, according to bug 15322 comment 43 (this bug blocks bug 48296), work on bug 15322 has been halted in favour of awaiting MPT's spec - which is now in limbo. If no more work is done on bug 15322, bug 48296 will never be fixed, and, therefore, THIS bug would still be halted. I've posted in bug 15322 seeing if work can resume there. (Jason may not have been aware that progress on MPT's spec had stopped.) If it can be resumed then I can make the appropriate dependancy reversal between this bug and bug 48296. Is anybody else as confused as I am? <grin>
Classic brain seizure. Replace bug 48296 in comment 141 with bug 48926.
It seems that this bug is getting hijacked by all kinds of other special interest wanting to push their own pet-peeve bugs forward. This bug is about the hopeful url bar seperation, not toolbar customization. If we stop trying to make this bug into one big fix for the Navigator UI, we might start seeing some progress for _this bug_. Maybe we need to make a tracking bug for need Navigator UI changes. Getting a list of needed Navigator UI changes under one meta bug would be the right direction to go. At least it is better then spamming this bug. Sorry for the spam myself!
hopefully most are aware of the completely sacrilegious nature of this activity. please remember that this and subsequent changes that are being proposed, would have to be implemented in a way that would not permanently affect Netscape, which wants to keep the current design. toolbar customization is being pushed heavily for the next release. if that happens, then this work will be mutually benefical. ideally this would be implemented so that each browser could choose its own default toolbar arrangement. at least that is the ideal we should be focused on. Let's not turn this bug into the validity of one design over another, because such a topic is not winable within confines of a bug.
Marlon: Please clarify your position on this bug. 1. Are you saying that Netscape is insisting that this bug (and related bugs) does not get fixed until Netscape is ready for it to be fixed? (That would be tantamount to admitting that Netscape controls Mozilla, something that's always been publicly denied.) 2. Are you in fact the module owner here and, if not, who is? 3. There is no "work" being done here (which may or may not be mutually beneficial) because this bug, and related bugs, have come to a halt due to dissension and lack of clarity, often with a perceived lack of adherence to the procedures in place to address specific bugs. At least that *seems* to be the case. If it isn't, which bug in Bugzilla *IS* being worked on towards the implementation of a new toolbar spec that we can look at? 4. Galileo was considered sacrilegeous, yet his was the correct viewpoint. <grin>
This bug should be marked wontfix imho. People seem to be split on how toolbar arrangement and customization should be developed. One is to move the address bar to it's own (this bug) then move on to allow customisation. Then there is some folks who seems to want customisation first so existing look can be maintained as default and people change it as they wish. Just two different way of thinking, I am inclinded to go with the later method, customise first, leaving changing looks to the user. This bug basically force interface change (maybe skins too) without advancing at all towards the ultimate goal (customisation).
> customise first, leaving changing looks to the user. Yes, but customization doesn't appear to be happening. If there were a bug number for it we could go to and get involved with that would be one thing - but there doesn't seem to be. It's in limbo. In its absence, waiting for something with not ETA at all (or even visible presence in any form) isn't the right solution. Besides, as I mention in 137 there are some approaches that could be taken to accommodate everybody.
You mean bug 15144? Seem to have some action starting.
The ultimate goal isn't customization, it is usability. There are serious usability issues with the current interface. Most of you are already painfully aware of them. For those who want a refresher, I'll point you to mpt's comments on this: http://mpt.phrasewise.com/stories/storyReader$35 Separating the toolbar from the address bar does not preclude maintaining the current interface look, if that is what users or Netscape prefer. Again, from mpt's original post here: "the Command Toolbar and the Location Toolbar should be split into two separate toolbars. These could be horizontally aligned to achieve the current layout, or realigned to achieve any of the layouts described above." The point is that the separation of the toolbar and address/location bar go hand-in-hand with customization. Now, that doesn't mean that they all need to be done in the same bug. But they all need to be done at some point. What good is customization if the only way to achieve a usable location/address bar is to remove needed toolbar buttons? I think you'll find many users who think that the toolbar is already horked up by the lack of the home button. But now I should remove forward and back buttons too so that I can get a location bar where I can actually see the entire URL? I can't see how that's a solution at all.
Maybe I am a bit stupid I don't see how separating the address bar with toolbar would suddently enhence usability. Does anyone actually can't find the current address bar to type the url? Didn't think so. In internet explorer I wield them together to save screen space. It's a matter of opinion on how you like your address/toolbars. Hence customisation. Having said that I never said separate the address bar is invalid, but this bug with it's current patch does nothing to solve the problem while possiblity introduce some new one. How will user react to the fact now there are even less screen space without the ability to do anything about it. It's not about what should be done (we got the spec), we all know the ability to customis is needed. It's about how to do it with minimal breakage. This bug has no benefit without the customisation stuff put in place. What mpt advocate is correctness, elegance and generally great for new users. But seeing mozilla 1.0 is already released, most user who want to try mozilla already did and got use to the fact that address bar are together with navigation buttons. Changing it now will introuduce inconvience to existing user without an option for them to go back (customisation again).
>Maybe I am a bit stupid I don't see how separating the address bar with toolbar >would suddently enhence usability. See comment 35
> You mean bug 15144? Seem to have some action starting. No, I hadn't meant that one specifically - but thanks for pointing it out. I'd been following bug 116183 instead, which looks like it's a duplicate. In any case, ALL of these changes are just subsets of what we'd like to see happen. Rearranging buttons is just one of the steps towards implementing a properly usable (configurable) UI. Moving / splitting / joining / aligning toolbars (in addition to buttons) is another part of it. Moving buttons is a necessary but still insufficient part of the whole. Ideally what I'm looking for is a meta tracking bug for UI customization / usablity. If I only hear about work on MPT's spec being stopped because of somebody's "boss", and I can't find a bug that directly relates to it, and nobody will step in and claim ownership of this particular module, (plus I read a comment from Marlon about how this bug is somehow a sacrilege against Netscape's plans, without an explanation of what those plans are, where they can be found, or why Netscape should have exacting control over Mozilla in this regard) then it's frustrating because the whole project is in some shadow realm that neither I nor anybody else not directly involved in it can gain access to. Whereas, with THIS bug, which is a small but still necessary component of the overall changes we want to see, I CAN get involved. But, again, discussion has been sidetracked. Can we get back to the question of a patch for this specific bug? > In internet explorer I wield them together to save screen space. bug 48926 > It's a matter of opinion on how you like your address/toolbars. > Hence customisation. Again, the point is that there *IS* no one, single, bug for "Customization". Not even, as far as I can tell, a meta tracking bug for it. So it's impossible that, suddenly, all of the pieces could just fall together. The mass of separate bugs on this issue, in a synergistic whole, seem to comprise what everybody wants. But some people don't want to work on A unless B is first done. While other feel the reverse it true. With that perspective, neither A *NOR* B will ever be finished. So work has to be finished on each bug as it comes along. In the end they will all fit together. This isn't, and it *CAN'T* be an all or nothing process. (Not unless you choose to go the "nothing" route, and I don't think that's what anybody wants.) But, again, discussion has been sidetracked. Can we get back to the question of a patch for this specific bug?
Aaron if you open mozilla in 800x600 you'll see that if we separate the address bar now the content area will only have around 60% of the screen height. I would be much more annoyed that the length of the address bar. Jason I just created a tracker bug 157199. It's not yet confirmed but hey, it's a tracker bug if needed. Not hard.
Other than Mozilla, name ONE browser that puts the URL bar on the button bar. You can't. So why is it so all-fired important to keep the URL box in the button bar? Home and Formfill buttons can be added, if you like. If Mozilla went away I guess Mike Tseng and Mike Lee wouldn't have a browser to use...
Blocks: 157199
>Aaron if you open mozilla in 800x600 you'll see that if we separate the address >bar now the content area will only have around 60% of the screen height. I would >be much more annoyed that the length of the address bar. That figure is entirely dependant on what OS, how big the taskbar is, and how many toolbars, etc. are enabled in Mozilla. The whole point is that a person can *eventually* be able to move and combine the status bars, etc. But we need to take this one step at a time. I personally am confident that if we get one of these patches reviewed, and get it put into CVS, the customization and layout issues that other people here are talking about will be soon to follow. Getting the address bar on a separate line will put pressure on the owners of the other bugs to get them fixed! Even if we don't get full address bar customization immediately, we can at least fill in some of the blank space with a Home button (which is bug 89350), etc. This will help to put pressure on the layout. (speaking of which, I am working on one as we speak, as per comment #113.) This should NOT be marked as WONTFIX or any other silliness. Sure, if we immediately put the address bar on its own toolbar, the navigation might look silly for a few weeks. But just look at how this thread *exploded* with activity. If we keep up the discussion and the work, we can get these issues solved. One step at a time though, this bug is blocking 7 others. Let's just get it reviewed and in the CVS, I say!
No longer blocks: 157199
Blocks: 157199
Added all dependencies on toolbars / buttons I could locate for the meta-tracking bug 157199. It came to 22 different bugs! As you can see, there is no single bug that, once fixed, enables customization. <grin> Mike Palumbo: I'm with you, man!
Yeah, I agree with you Mike Palumbo. We have to start somewhere, and this bug is a good start. Maybe this can get into the trunk sometime after the 1.1 branch?
I don't think you people realize what a can full of worms this bug is. Not only is it about the most controversial aspect of Mozilla; its UI, it is also about the lack of enforcement of volunteers' UI design specs (mpt's, in this case) and the inability / reluctance for drivers to tackle this issue. That said, I don't think you make it easier for yourselves by morphing this into an even more huge bug which will solve all other UI bugs in bugzilla.
Please do not SPAM this bug. Keep discussion to technical merits / detriments of patches to address Nav/Address toolbar separation only. Arguments against this specifically, and UI in general, should go to newsgroups. Others: From now on let's try to simply ignore further debate teasers and keep ourselves focused on the task at hand.
Patch status: With all of the "discussion" it's easy to lose track. Is there a patch that's been submitted that proponents of this bug agree upon? With the exception of the addition of a "Go" button (that's not part of the original Nav/Address toolbar) http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view looks good. This specific bug shouldn't be about adding anything else. In fact we might want to remove the "Go" button, but if nobody else thinks so I'm happy with its inclusion. Does that screen shot have a corresponding patch submission?
>With the exception of the addition of a "Go" button (that's not part of the >original Nav/Address toolbar) >http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view looks good. > >This specific bug shouldn't be about adding anything else. In fact we might >want to remove the "Go" button, but if nobody else thinks so I'm happy with >its inclusion. The GO button has been around for quite some time now. It is not an addition. Through the preference panel, it can be hidden or shown. The separation of the toolbar and address bar should not add or remove features including this one.
> Through the preference panel, it can be hidden or shown. Oh, good - so it's presence would still be linked to the preference. It wasn't entirely clear from the screenshot (obviously) if it was hardcoded or just enabled in that instance. I agree totally that nothing should be removed or added from what we have now.
No longer blocks: 48820
No longer blocks: 64073
Note: This needs the updated btn1.gif to work in Modern. It appears to work in Classic but you'll probably want the new home gifs.
Attachment #66757 - Attachment is obsolete: true
Effort appreciated, but we don't want a home button as part of a patch for this bug. A home button is addressed in bug 89350. We don't want to add or remove ANY features from the existing Nav/Address toolbar for the purpose of solving this one particular bug...
Attached patch Just the basic split (deleted) — Splinter Review
Excellent! Can you also attach this patch to bug 157199 and name it "Patch for bug 49543"? We want to track the patches for each part of MPT's spec in that meta bug also. (Ideally, having not only each sub-component patch but also a "meta patch" based on the combination of all of them. That way MPT's spec can be reviewed not only on a piecemeal basis but also as a whole.) I'm tempted to mark all other patches, MPT's spec, and screenshots of things like home buttons as obsolete since they don't apply to this bug directly and only confuse the issue. But will wait for feedback from others on that.
> I'm tempted to mark all other patches, MPT's spec, and screenshots of things like home buttons as obsolete since they don't apply to this bug directly and only confuse the issue. But will wait for feedback from others on that. They don't belong here at all, but they're still important. Maybe they (the most important from them) should be linked to in a comment in the meta bug.
Linking them to the meta bug make sense. But can't we do that while still removing them from this bug? I'm just now downloading / uploading MPT's spec so that I can attach it directly to the meta bug and obsolete it from this one. Other bugs should be handled in a similar fashion where appropriate.
Re: Additional Comment #168 From Jason Bassford 2002-07-15 07:45 > But can't we do that while still removing them from this bug? Does marking an attachment obsolete remove it? I don't think so.
> Does marking an attachment obsolete remove it? No, annoyingly enough. Nor do I seem able to even obsolete an attachment without first creating a new one. I guess that for now we'll just have to live with copying appropriate attachments over to the meta bug and trying to ignore extraneous attachments here. I've made a first start.
Comment on attachment 65067 [details] Spec for toolbar arrangement and customization You have to hit Edit to obsolete attachments.
Attachment #65067 - Attachment is obsolete: true
Attachment #64824 - Attachment is obsolete: true
Attachment #64763 - Attachment is obsolete: true
Attachment #64825 - Attachment is obsolete: true
Attachment #64826 - Attachment is obsolete: true
Attachment #74549 - Attachment is obsolete: true
Attachment #91327 - Attachment is obsolete: true
What is the status of "Patch v2"? Is this an alternative to the most recently created, or is it now out of date?
mpt's specs (attachment from 2002-01-15) don't include a *Print* button. Why not? Has there been a discussion on this. I would think most "common" users (incl. my parents) would _much_ more often want to "Print" than "Edit" (which strangely is included in his specs). I strongly disagree with this part of the "spec". I also realize that this is not the right place to discuss this issue. So ... where can I bring up my objections to this part of mpt's (otherwise good) specs?
------- Additional Comment #173 From Peter Lairo 2002-07-15 11:38 ------- > mpt's specs (attachment from 2002-01-15) don't include a *Print* button. Not true. It's just not mentioned. Quote from IRC: <mpt> Oh yes, there are lots of buttons that would be off by default <mpt> Print, Save, Zoom, Encoding, Style, Preferences, New Window ... > Has there been a discussion on this. I don't think so. > I also realize that this is not the right place to discuss this issue. > So ... where can I bring up my objections to this part of mpt's (otherwise > good) specs? netscape.public.mozilla.ui, as has been mentioned several times.
Comment on attachment 91339 [details] [diff] [review] Just the basic split >+<!ENTITY locationToolbar.tooltip "Location Toolbar"> Elsewhere in the UI, it's simply referred to as the 'Location Bar'.
> (From update of attachment 91339 [details] [diff] [review]) >> +<!ENTITY locationToolbar.tooltip "Location Toolbar"> > > Elsewhere in the UI, it's simply referred to as the 'Location Bar'. Elsewhere in the patch you mean? It can't be the rest of the UI because the Location Toolbar is a new toolbar, are you confusing it with the URLbar? Sorry about that, it's a mistake from undoing the renaming to Address Bar. <!ENTITY locationBarCmd.label "Location Toolbar"> is correct.
>> (From update of attachment 91339 [details] [diff] [review]) >>> +<!ENTITY locationToolbar.tooltip "Location Toolbar"> >> >> Elsewhere in the UI, it's simply referred to as the 'Location Bar'. > > Elsewhere in the patch you mean? It can't be the rest of the UI because the > Location Toolbar is a new toolbar, are you confusing it with the URLbar? Yeah, probably. I meant in places like the Preferences where it's referred to as the "location bar". But I guess that's just referring to the actual text field. > Sorry about that, it's a mistake from undoing the renaming to Address Bar. > <!ENTITY locationBarCmd.label "Location Toolbar"> is correct. Looks like that. I checked 4.x and it uses 'Location Toolbar' so you're right.
*** Bug 43739 has been marked as a duplicate of this bug. ***
Attachment #65067 - Attachment is obsolete: false
Comment on attachment 91339 [details] [diff] [review] Just the basic split Marking needs-work, since it doesn't move the Home and Search buttons. (I suggest obsoleting this patch in favor of attachment 91327 [details] [diff] [review].) The split+move would make Navigator more usable for perhaps a few tens of millions of people, and less usable for perhaps a few tens of thousands of people.* (That's one of the reasons why it should be done regardless of any customizability.) For split-by-itself, however, this would not be the case: the only immediate improvement would be the lengthening of the address field, which wouldn't be enough to justify the loss of vertical content area. To fix this worst UI problem in Mozilla, there are two possible approaches. (1) Wait for Netscape to fork the UI, so that those acting to minimize the number of Mozilla/Netscape/etc users (Netscape UE) are no longer sabotaging the work of those acting to maximize the number of Mozilla/Netscape/etc users (most other contributors). The current toolbar layout makes Netscape much harder to use, so Netscape want to retain it (comment 144). This is why, for example, they claim repeatedly that this bug is dependent on toolbar customizability (e.g. comment 45, comment 50, comment 128), when such a claim is the exact opposite of the truth (comment 33). They know what they're saying is complete garbage (it is disproved by almost all other browsers, including 4.x), but the resulting talkfest achieves its purpose of delaying this bug. (2) Get a patch reviewed, and super-reviewed by a module owner, neither of whom are subject to Netscape's chilling effect. For r=, there are plenty of candidates. For sr=, Hyatt is the obvious choice, since (a) he is one of the module owners for the Navigator front end (Marlon is not), (b) he isn't employed by Netscape, and (c) navigator.xul begins with an order to get sr=hyatt for any changes. :-) I suggest approach (2), since if you try (1) you'll go old and gray, and Mozilla's UI will get worse in other places while you wait. (I should know, I tried it for a few months recently.) While that is happening, PLEASE DO NOT SPAM THIS BUG REPORT unless you are (a) attaching a patch or (b) reviewing a patch. * Yes, these are guesses based on heuristic evaluation. That's what I deal in. Some things can't be measured using jprof.
Attachment #91339 - Flags: needs-work+
Sorry for the spam, but there are working patches up here; who can we get to review them? I refuse to see this bug become stagnant.
Well, if you read bug 161857, it would seem that the add/remove buttons panel is going to be removed in favor of toolbar customization. If that actually ever happens, so this bug will most likely be fixed once (if) that really takes place. "------- Additional Comment #4 From Blake Ross 2002-08-09 00:19 ------- We are getting rid of that toolbar pref panel, to be replaced by toolbar customization (actual, real, non-lame toolbar customization.)" You could also try a build of Phoenix. That already has basic customization implemented already (although sadly you still can't remove the url bar from the nav bar to it's own line, at least in the build I used). Or you could also just give up on this bug and it's blockers and all the jibber-jabber and patches that just get denied/ignored and just turn to using IE instead as I have.
> If that actually ever happens, so this bug will most likely be > fixed once (if) that really takes place. There is no guarantee that it will ever happen. How can we be expected to close this bug in the meantime? It's not a duplicate of "Phoenix" (this one was opened first and Phoenix is not expressed as a bug number in Bugzilla in any tangible fashion), which *appears* to be closed-source to a few number of developers who are working on their own without communicating much of anything back to the community about intentions, target milestones, or methods of approach. Yes, you can download some recent builds and see some screenshots - but nothing has yet been stated as to how / when any of it will be incorporated into Mozilla. In the absence of anything definite, it can only be treated as "vaporware" as far as Mozilla itself is concerned. Perhaps not as far as the developers in question are concerned, but certainly as far as anybody not directly involved is concerned. > Or you could also just give up on this bug and it's blockers and all the > jibber-jabber and patches that just get denied/ignored and just turn to using > IE instead as I have. That doesn't help either. This is a Bugzilla entry and should be discussed on its own merits. Expressions of curiosity / desire for forward momentum here is understandable and the way that things should work. If the people at Mozilla who are responsible for controlling check-in approval of the various bugs open on toolbar customizability KNOW that they are working on something else that will one day (soon I hope) appear in Mozilla full-blown due to this work, and they know that patches to these existing Bugzilla bugs will not ever get approval - then they should just close all of these bugs as WONTFIX or INVALID and save everybody the bandwidth. However, so far none of the module owners have taken responsibility for any of these bugs - nor is there even a concensus (or admission) of who the module owners happen to be. The lack of any such communication means that there is no official mozilla.org stand on these issues, so they remain open. While they *DO* remain open, they should be treated just as any other bug...
> this bug in the meantime? It's not a duplicate of "Phoenix" (this one was > opened first and Phoenix is not expressed as a bug number in Bugzilla in any > tangible fashion), which *appears* to be closed-source to a few number of > developers who are working on their own without communicating much of anything > back to the community about intentions, target milestones, or methods of > approach. Yes, you can download some recent builds and see some screenshots - > but nothing has yet been stated as to how / when any of it will be > incorporated into Mozilla. No, Phoenix is not a bug number in Bugzilla. It is a "product name", so you can go to the Bugzilla query page and select Phoenix to see all Phoenix-related bugs. It is not closed-source, either. I've been building and using it since it came out. The source _is_ part of the mozilla tree and can be pulled with cvs. IMHO, in the end, it doesn't really matter whether any of it gets into the default mozilla/netscape "build". The source is out there, and distributions like Red Hat will ship whatever they want to ship. (From the current beta, it looks like RH 8.0 will ship mozilla for browser and evolution for email. I won't be suprised if the next version uses Phoenix plus Xft support.) This bug is just over 2-year-old, bug 15144 is approaching 3 years old, and bug 89350 was just WONTFIXed. I've given up on this and all related bugs. It is quite clear that "they" simply won't fix these bugs. Sorry for the spam. Anyway, I hope Phoenix will become what we all want.
Whiteboard: [geekweb-fixed]
If people want to fix this, it would be _easy_. You need just take the phoenix code and port it to the xpfe codebase.
Hixie: Only once it's working properly in phoneix, of course - currently it does nasty things with window.open flags, for instance...
there's no point in discussing the code here. it wouldn't matter if it was a one line change; this bug isn't going to go anywhere until someone who can authorise significant UI changes makes a decision to allow it to happen...
Who's against it?
Netscape. See comment 144. If this is wanted, I could attach a patch as well. See <http://www.developer.beonex.com/beol>, this bases on Communicator codebase. Creating this separation was not that hard. Code isn't the problem here.
FYI, so that nobody misunderstands my last comment: IMO, it is totally OK that Netscape is against this change. It is a controversial decision (I'd guess that many Mozilla users would disagree with this bug as well), and Netscape opted this way. Keeping Mozilla close to Netscape 7 makes IMO sense, at least in this case. I agree that toolbar customization is what's wanted, and with the Phoenix work, we are now closer than ever (actually, IMHO that's the coolest thing of Phoenix at all). All we now need, basically, is the Phoenix implementation to settle and then merged with or ported to Mozilla. (Right?)
Gee, I hear Netscape may be interested in Phoenix features such as this one. Times do change. Someone should do a patch that works, doesn't regress default appearance, and doesn't hurt tinderbox performance numbers (much; drivers will negotiate). Then we can talk. Sitting here fretting about something someone from netscape.com said a while ago doesn't do anyone any good. /be
NS does want toolbar customization, and this could be part of it. ->module owner, nominating for Buffy, cc patricec (who is our browser UE rep).
Assignee: nobody → blaker
Keywords: nsbeta1
QA Contact: claudius → paw
Always makes me wonder about this bug why it isn't marked as depended on bug 15144. Let's be honest. There are valid objections to that dependence (see comment 33) but, since Netscape has decided to give priority to customization, I see no point on insisting the opposite. A dependence field might not be that important to the resolution of this bug but, at least, would prevent whining on the lack of progress.
As Peter mentions in #191, the separation of the Location Toolbar is part of the next release.
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [geekweb-fixed] → [adt1][geekweb-fixed]
.
Assignee: blaker → shliang
Marking nsbeta1-.
Keywords: nsbeta1+nsbeta1-
Whiteboard: [adt1][geekweb-fixed] → [geekweb-fixed]
What will happen with this bug when Mozilla 1.5 is launched? Mozilla 1.5 will have customizable toolbars in the browser and mailnews.
As with all bugs in this situation, the reporter is free to close it as INVALID or WORKSFORME if they feel that the problem is no longer pertinent to the new browser engine. (Or they can leave it open if they still want the Seamonkey engine fixed.)
it is my hope that seamonkey will still be maintained. I would, therefore, not resolve this bug until it is clear that that is not the case.
a separate url bar is the most critical feature missing from mozilla/netscape
the point of having a url bar is that it shows the url. currently, the url bar does not show the url. it shows http://bugzil and http://www.go (there is no way of determining or modifying which url you are at without maximising the screen). ever tried navigating without knowing your location? so judging by the dates on these comments, the people responsible for the UI of this product have for the last 2 years, either been using internet explorer, been dividing their desktop into 1600x600 slabs, or have never typed in anything beside a domain name.
Once Firebird is finished, and Seamonkey no longer needs to be maintained because Firebird is everything Mozilla was and more, and becomes Mozilla, won't this bug be irrelevant?
thanks. yeah firebird is goodstuff and it solves this issue http://www.mozilla.org/projects/firebird/
yeah and it was a joke - not directed at anyone - i have just been looking for a UI fix for a long time. you open source people do a good job.
Blocks: majorbugs
Is there *anything* I can do to get this patch into the nightlies ? I agree with Comment #120. There's a patch that fixes this bug. Get the patch into the nightlies, mark this bug fixed, and move on. I disagree with Comment #128. If a quick hack can make "some users" happy, let's do it. I basically agree with #202: Once the "latest testing release" browser at http://mozilla.org/ fixes this bug, then this bug can be marked fixed. -- David Cary
Re comment #205 I have been reading the book called "Rapid Development" by Stephen McConnel (about project management and how to avoid mistakes), and that paired with my experience on this project has made me change the stance on that as of the last year or so. Checking in "quick fixes" has turned the codebase into a beast like Jason Kersey said and I think we want to move now with the new Roadmap direction to something more deliberate with plan schedules for inclusion of features and strict checkin management (especially with Firebird) or we will just have another mess. If you want to see this in action, just watch successive windows releases. It says in the book that doing something wrong the first time can cause 10 times the man hours down the line. It makes sense because new code will depend on the incorrect code as it is added. Besides the fact the patch is over a year old and already said it needed work, putting in a fix like this would mean that we would have to come up with a plan to implement this correctly. An, "Let's do the hack now and fix it later" rarely works as outlined in the book "Rapid Development". If you can come up with a schedule for doing it right, and find someone who will agree to follow the schedule, then it might be OK. Otherwise, what will probably happen is someone will have to rewrite everything down the line, or it could cause maintenance issues.
Product: Core → Mozilla Application Suite
No longer blocks: majorbugs
Resetting A+QA after more than 4 years since last comment, more than 5 since last patch. I expect this bug to wait till after toolkit customization of toolbars is brought over to SeaMonkey (and maybe some more) -> changing dependencies to reflect that. Please undo if I goofed.
Assignee: shliang → nobody
No longer blocks: 15144
Depends on: 15144
QA Contact: pawyskoczka → guifeatures
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
Priority: P3 → --
QA Contact: guifeatures
No longer depends on: 15144
Actually fixed by Bug 394288 since you can now create additional custom toolbars and then drag and drop the urlbar on to it or any other customizable toolbar in the toolbox.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: