Closed Bug 49543 Opened 24 years ago Closed 15 years ago

Separate Toolbar from Address Bar [urlbar]

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mpt, Assigned: jag+mozilla)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [geekweb-fixed])

Attachments

(4 files, 15 obsolete files)

Screenshot
29.88 KB, image/gif
Details
Patch v2
33.66 KB, patch
Details | Diff | Splinter Review
Spec for toolbar arrangement and customization
31.38 KB, text/html
Details
Just the basic split
10.47 KB, 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 file Modern home button images (obsolete) — 

    
  

        Attachment #51213 -
        Attachment is obsolete: true

    
    

    
  
Neil, can you attach a screenshot of how it is supposed to look?

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot (48K) (obsolete)
        — 
      

    


  

    
    

    
  
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

    
    

    
  


  
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
        — 
      

    


  

        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)
        — 
      

    


  
You need this image in themes/modern/navigator/icons to test the patch.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v1 (obsolete)
        — 
          — 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)
        — 
      

    


  
New home.gif for the Classic theme

    
    

    
  

      
      
      
      

        Attached image
          
        home-active.gif (obsolete)
        — 
      

    


  
New home-active.gif

    
    

    
  

      
      
      
      

        Attached image
          
        home-hover.gif (obsolete)
        — 
      

    


  
New home-hover.gif

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v2
        — 
          — 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)
        — 
          — 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.

    
    

    
  


  
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...

    
    

    
  
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: nsbeta1 → nsbeta1+
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: 15 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: