I think that Navigator and Messenger (at least) should have a Preferences Toolbar, to allow quick editing of the most common preferences for that component. The toolbar would be off by default. This would end the whinging of 4.x users that certain prefs which were accessible with a simple menu click in 3.x now require them to ferret deep into the prefs dialog. Straw-man proposal for contents of the Preferences Toolbar in Navigator and Messenger: Navigator --------- [Style :^] [Size :^] [*] Custom fonts [*] Custom colors [*] Images [*] JavaScript Messenger --------- when an HTML message is being shown: [Style :^] [Size :^] [*] Custom fonts [*] Custom colors [*] Attachments in-line when a plain-text message is being shown: [Style :^] [Size :^] [Wrap mode :^] [*] Color quotes [*] Attachments in-line

This would be a pretty cool feature, especially for those times when you want to quickly toggle a pref in a matter of minutes (e.g. "this damn site is using JS to block me from right-clicking to get the context menu; I want to turn off JavaScript just while viewing this site, but then I want to turn it back on")

Then again, support for URL-by-URL prefs (is this landing soon? or ever?) would resolve the case I just mentioned

This is a pretty cool idea and one that certainly warrants more discussion. It's not likely to go into this version, though, so I'm resolving this as "LATER." We can come back to it in the next round.

Reopening and setting milestone to Future. LATER is deprecated.

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

I'd also welcome this feature. Having used a browser with (basically) these options, I know how useful it can be. Some comments however: - Please add sound to the list - Separate settings for background and foreground images - Any links followed which are on the same site should inherit these settings. Other links could be allowed to revert to the default settings (ie as set in prefs) - Might also be good to add (inline) plugins to the list of victims. Some of these can be damn annoying (the Crescendo Midi player springs to mind :) Some addition discussion on this topic can be found in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=38392">bug 38392</a>.

Reassigning from bdonohoe to hangas

Interesting, marking as future.

See also bug 20826, buttons to toggle images/java/javascript/etc.

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

Great idea! Java should perhaps be in the list as well, and I'd like to see image animation included. Even better, eventually allow users to choose which prefs they consider important for this toolbar -- a "personal prefs toolbar".

updating to new owner. sorry for the spam.

What do people think about making prefs changed on this toolbar only affect the page that you're on? Would there be some visual indicatation on the icons that the type of content (images/javascript/etc.) they represent existed in the current page? For example, I want to know whether the current page has a javascript or not. See bug 42658.

Personally i'd like a small dropdown: Global | Domain | Site | Window | Page but i'm not sure i can explain this to an end user.

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

> What do people think about making prefs changed on this toolbar only affect > the page that you're on? I think it would be incredibly annoying, not to mention defeating much of the purpose of the `Images' and `JavaScript' toggles in particular (since once you turned those off again on a new page, it would often be too late).

I put together a quick rendition of this at http://www.xulplanet.com/downloads/misc/prefbar.xpi. It's still very basic, and contains numerous bugs (the largest of which being that it doesn't update itself when somebody else changes the prefs involved) but is fully functional, at least for the two preferences it currently includes. This was designed for mozilla 0.8.1, so it probably won't work with the latest nightly builds.

Aaron Andersen: Great. But hang on... why isn't this a sidebar panel rather than a toolbar? An extra toolbar is always covering your content area. A "Hackers Sidebar" would be really cool - all those useful prefs that power users like, and you can hide the sidebar by double-clicking the grippy when you weren't using it. I had this idea a while back but never got round to it. Also, the sidebar might make it in to CVS - I very much doubt an extra toolbar will. BTW, one feature - at the bottom, a text box for a pref name and another one for the value, so people can change their favourite prefs without needing UI for all of them :-) Gerv

>Aaron Andersen: Great. But hang on... why isn't this a sidebar panel rather than >a toolbar? It's a toolbar because that is the title of this bug, "Preferences Toolbar, for most commonly used prefs." It could just as easily be in the sidebar, and if it is agreed (by mpt et al.) that a sidebar panel would be best, I'll change it.

if you don't mind implementing a sidebar too for now, that'd be great, i think there's a separate bug for it.

A toolbar is less intrusive: you can keep it on all the time without taking away much space from content.

A toolbar is _less_ intrusive? It would cover a good centimetre of the vertical content area and (given that pages are vertically oriented and screens are, for some reason, wider than they are high) vertical space is in short supply. It would also cover it permanently, whereas a sidebar panel could be flipped out at a moment's notice, or even left open (taking up horizontal space.) Gerv

Bah, <sidebar/> and <browser/> need to live in a <bulletinboard/> so that people can make sidebar float or dock left/right. Actually, if done right, toolbars could be docked or floated as sidebars... How hard is it to make a panel that will display reasonably well in either a horizontal or vertical rectangle? [Mozilla's box system unlike html seems to prefer fixed orientations and no optional wrappings]

Toolbar: * Can be easily turned on or off (through the `View' menu, or -- eventually -- the context menu for the toolbars themselves). * For a maximized browser window on an 800*600 display, takes away about 16,000 pixels from the content area. Sidebar panel: * Can be easily turned on or off (through the `View' menu, or by dragging the splitter). * For a maximized browser window on an 800*600 display, takes away about *75,000* pixels from the content area. And that, my friends, is why it should be a toolbar rather than a sidebar panel. Besides which, I suggest that the intersection set of those people who would like this sort of UI, and those people who dislike the sidebar in general, would be quite large. If you want a prefs sidebar panel, please file that as a separate RFE. Thankyou.

I have completed the second version of my prefbar overlay. This version is a lot nicer than the last one, and includes more preferences. Any feedback, suggestions, bug, etc. would be appreciated. Also note that the toolbar now has a context menu from which you can show or hide the different prefs on it.

Aaron: are you still using the URL http://www.xulplanet.com/downloads/misc/prefbar.xpi ? Because the XUL there seems to have blake's Value/Label disease. If not, could you upload your new version somewhere? Preferably both as an XPI and raw files... <bluesky> Could you not have a context menu item "Add pref" which, when given the name of a pref, determines its type and adds the name and a sensible type of control to the bar? Also, the bar could scroll if it gets too long... </bluesky> Gerv

If you are talking about bug 70746, that is because this was written for 0.8.1, and as such doesn't have any XUL 1.0 stuff in it yet. I have been too busy lately to keep track of which of the XUL 1.0 bugs have and have not been fixed right now. When 0.9 comes out I will update this for whatever XUL 1.0 stuff is in by then. The problem with user added prefs is that although we can check from nsIPref what type a certain pref is, there is no way (that I know of) to determine what the different values really mean. The image loading pref for example, is an int pref, and takes either 0, 1, or 2, for off, server only, and on respectively. So although I could convert the image pref to a drop down box (to allow selecting of the server only option) I can not think of a feasible way of having the user add a new pref to the bar. My current plan was just to include an extremely large number of prefs (with only a few turned on by default) and let the user choose which ones to include via the context menu. (If you know of a pref that should be included that currently isn't, let me know) However, if you can think of a better way of doing things I'd love to hear you ideas...

Re: user-added prefs. It's true you can't sanity-check them, but it would be a "user's own risk" thing. I agree you should have a large number which you've built in, certainly. Gerv

It's not about sanity-checking, it's about how the user is going to be able to do this. Take the cookie pref for example. If I hadn't included that one already, there would probably be a user or two who would want to add it. However, in order to access a preference, nsIPref needs to have the prefstring. Without looking at the source code for the preferences dialog, how is this user going to know that the prefstring is "network.cookie.cookieBehavior"? And even if the user knew that, what then? The app would tell him that the cookie pref is an int pref. But how is the user going to know what numbers mean what? (0 is off, 2 is on, and 1 is server only.) And after all that, what kind of a control should be used? A textbox? That wouldn't be very convenient, because the user would have to constantly remember what numbers to use. But any other control would require additional information from the user. A checkbox (like I have now) would have to know what int value the checked and not checked states stood for (currently 2, and 0 respectively), and a drop down would require a list of different options, with an int value and label for each. If you've looked at the source code you know that my method of doing things isn't very pretty either, but the ui for it is clean and simple. It just seems to me like any method for allowing the user to ad a pref to the prefbar would be extremely complicated and require more work on the part of the user than just opening up the .jar file and adding the new pref manually. Remember that there are only a certain number of prefs in the product, and most of them don't need to be included here. I see no reason why someone would ever need to change the homepage URL, or the number of days pages are kept in the history file using the prefbar. Like I said, if there is a pref that I haven't included that you want or you think someone might want, let me know and I will add it. But I don't think user-addable prefs would be worth the time and effort that would be required to make it work. Aaron

OK, fair enough. I'm convinced. The prefs toolbar is not the place for this function, if it is indeed necessary. :-) Gerv

I always thought it'd be nice to have a sidebar that let you edit ANY pref. Something similar to the way regedit works in Win32 where you have a tree view and you can add, remove, and change settings with relative ease. Perhaps this could be a an advanced mode? Or is this beyond the scope of this particular bug? Please note that when using regedit in Win32, it is assumed that you are reasonablly comfortable with what a setting is and what its possible values are (just like when you edit prefs.js manually).

That's a different bug - bug 17199. Gerv

Making this toolbar customizable should be filed as a separate RFE depending on this one.

>Making this toolbar customizable should be filed as a separate RFE depending on this one. Which should probably be dependant on bug 17199 also, because a fix for 17199 would make it not quite so impossible to do a customizable pref bar.

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

In a related note, my prefbar xpi is now updated for mozilla 0.9, and located at http://www.xulplanet.com/downloads/view.cgi?catagory=applications&view=prefbar All future updates will be at this location. As I said before, I could really use some feedback on the design, included prefs, and/or backend implementation, so if anybody has any comments, send them to kc7gza@hotmail.com (or post here, if appropriate).

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

The interesting question remains which aaron alludes to: would prefs controlled by the toolbar only apply to the document being viewed or would they change the gloabl prefs? While I am sure the author meant to change the global prefs, usability data I have seen before suggests that many users might not expect to change their global prefs but only to apply this fr the local document, or the session of the current window, because of the way it is presented (as a toolbar).

I think there is so much unused space on "status bar" and it could be used as a place for some icons like: [java on/off] [javascript on/off] [images on/off/current only] [cookies on/off/cur] Just theese four buttons somewhere near to [online/offline] indicator and [security] button. Is it a different "bug"?

Yes it is a different bug, and a highly wontfixable one at that. German: > > While I am sure the author meant to change the global prefs, usability data I > have seen before suggests that many users might not expect to change their > global prefs but only to apply this fr the local document, That would be incredibly annoying, not to mention defeating much of the purpose of the `Images' and `JavaScript' toggles in particular (since once you turned those off again on a new page, it would often be too late). > or the session of > the current window, because of the way it is presented (as a toolbar). Good point, I hadn't thought of that. Yes, it should apply only to the active window, and settings from the last open window should be saved on exit. However, I think the people who would use this feature in the first place could put up with the prefs being global until that further enhancement was made. --> XP Apps: GUI.

For anyone interested: I have just filled Bug 87538 (enhancement) about preferences buttons on status bar (buttons like online/offline and security buttons). (Hoping it's not a dupe, I failed to find this in bugzilla)

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

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

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

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

Hi guys. :-) I'm new to XUL and I've been following this enlightening discussion. Would it be possible to do this toolbar at the BOTTOM of the browser, in the place currently used for the "Status bar" (or whatever is the exact name for the place where the text 'Document: Done (x.xx secs)' is placer)?. See the following screenshot for my view on how I'd love to see this implemented (probably along with a small drop-down) to select between this and the default status bar behavior. :) Regards Fernando

Fernando: see bug 87538 (apparently you failed to read previous comments) Your screenshot eats almost all of the status bar. It wuold be better to have just small buttons like security button on the right to eat just a small space from the right side of status bar. There's no need to have text and checkbox on preference button - just the change of shape/color would indicate state of button (like security and online/offline buttons does). f.e. Java button could be a cup of coffee: when turned OFF -> empty grey cup when turned ON -> colourfull cup with steam from hot coffee (with tooltips "Java: ON" and "Java: OFF" when mouse over) More debate on preferences buttons on status bar should go to bug 87538, it's OFFTOPIC here.

Having read this entire thread, it seems this proposed feature is aimed only at developers. I don't see the case for providing this to millions of end users who would only be confused by it and don't have a pressing need to be flipping these values more than once in their lifetimes. If this developer tool gets implemented, it should be distributed as such - a separate xpi that can optionally be installed by developer users. Aaron Andersen has demonstrated that this is a sufficient distribution mechanism for those who want it. Since this bug is proposing a permanent change to the UI that is targeted at a very small user group, I suggest that it should be marked WONTFIX and those who want this feature should build it as a separately available xpi.

selmer is correct; IMO this should not make it into the main Mozilla distribution. However, if leaving this bug open would help development of the XPI, that's not a problem. Gerv

I thought that this was a feature a lot of users might like: e.g. leave Java off until they go to a site that really needs it leave JS on until they hit a site that keeps popping up windows, then turn it off right then; leave custom fonts on until they get to a page that's unreadable. I'm not sure what any of these have to do with whether someone is a developer; if anything I would have thought that newbies (those who don't understand the prefs dialog) stood to benefit the most.

The fact that these features are useful does not necessarily mean we need a new toolbar. Computer monitors are vertical-space-poor and horizontal-space-rich compared to how people like to read documents. We should avoid taking more vertical space than is absolutely necessary. Note that the <LINK> element navigation toolbar will soon be checked in - this is something that makes us more HTML 2 (!) compliant, and is potentially useful to all users. If we are to have another toolbar, that is a much better candidate, because widespread deployment will encourage adoption of <LINK>. A similar argument cannot be made for the prefs toolbar. The fact that mozilla.org perhaps does not do as good a job as it might of making people aware of all the cool additional stuff they can install is a separate problem. Gerv

I agree w/ Gerv that using more horizontal space might not be a good idea, but I think Akkana is right in assuming a high number of potential "frequent pref changers". In my environment I've seen recently quite some people trying Galeon for the first time. They liked the UI speed, and *all* of them liked the "Settings" menu to quickly switch on/off JS, Java, proxy, imgs, and so on. It appears to me that the Galeon people hit the right nerve with that menu, and I presume that most supporters of this bug could live with such a solution.

I'm not saying that this UI should not be more prominent, my point is merely that a toolbar is the wrong place for it. A menu would also have to be removed by all distributors whose target audiences were not hardcore techies (What Mozilla's target audience is, in UI terms, is still a matter for debate.) This is why I continue to suggest that the best place for this UI is a sidebar panel. It can be installed with a single click on a link, reduces horizontal rather than vertical space, and can be put away easily when not needed. Gerv

Perhaps my use of the word "developer" is too charged. I said that because I hadn't seen any evidence that this was driven from an analysis of actual end-user usage patterns. I agree with Gerv that a sidebar panel is the best way to address this for now. If the sidebar panel becomes wildly popular, then that would justify giving it greater precedence in the UI later. In any case, I don't agree that this toolbar should become part of the standard product at this time.

I won't argue the inclusion or not (especially in the Netscape client; Mozilla folks can make their own decision) or the priority (which is a function of when someone has time to make it happen). But let's please not morph this toolbar request into a sidebar request: see mpt's comments of 2001-04-24 08:35 for why not.

As per mpt's original bug description, this would be a toolbar that defaulted to being turned off. Therefore the toolbar is not going to waste any verticle space unless the user decides to turn it on. Since there is a functional toolbar solution, why discard it? If some people would prefer a sidebar solution, then open a new bug and let someone come up with a sidebar solution, but do not ignore the users who would prefer the toolbar. I also do not understand the opposition to having this toolbar included in the standard build of Mozilla. The resource overhead of this toolbar is minimal and it defaults to being off. I do not see how inclusion of this toolbar would cause any problems for anyone who does not want it enabled. However inclusion would be very convienent for those who are interested in using it; otherwise it has to be reinstalled each time a new Mozilla build is used AFAIK. Also many users who would like to have this feature do not even know Aaron's toolbar exists so how would they know to download and install it?

I filed this RFE because: * there are some prefs which (contary to selmer's assertion) advanced users want to turn on and off quickly, and I have seen many comments in newsgroups and Web discussion forums to that effect; * unlike with 3.x or earlier, when Mozilla's user base was (on average) much more technically-minded, such options do not deserve a top-level menu of their own; * such prefs could be toggled much more quickly from a toolbar than from the prefs dialog, even if the toolbar was hidden initially; * such a toolbar could be off by default, and access to it would be very unobtrusive for those who weren't interested in it (second from bottom of the `Show/Hide' submenu, and third from bottom in the context menu for any toolbar). The longer Mozilla lacks something like this (in the default distribution), the more duplicates this bug will collect, and the more potential contributors will use browsers like Galeon, iCab, or Konqueror rather than Mozilla.

> Since there is a functional toolbar solution, why discard it? No-one is suggesting discarding it; my assertion is that it should be an XPI. And yes, we need a page of "cool stuff to install in your copy of Mozilla", and I've asked several times in the newsgroups for someone to write one. There's a load of cool stuff that Mozilla can have added to it; in each case, we have to ask whether it should be in the default build, or whether it should be an XPI. There are no criteria for this that I know of - it's a case-by-case thing. But the question is not "why shouldn't it be in", it's more "why shouldn't it be an XPI"? Gerv

I suggest an obvious solution to getting people's attention to cool-addons with a new default installed Sidebar for "Mozilla Add-ons"..

xul patch prefbar from xulplanet has problems with javascript not keeping the setting for JS on/off also there is problems with the bookmarks in prefbar folder because of the patch, so in essense it is not working on newer builds since patch was created where after awhile the user only sees the first 3 options in the bookmarks toolbar menu. Which has generated bug reports of bookmark problems. http://xulplanet.com/downloads/view.cgi?category=applications&view=prefbar -dennis

Adding self to Cc, I love this thing, but I hate reinstalling it for every version. When can we get this thing into the distribution? I don't mind if it's turned off by default; View->Show->Preferences would be a *lot* easier than redownloading it every time. > A toolbar is _less_ intrusive? Most definitely. I *hate* the sidebar and want it to go away forever. Toolbars are quite useful, and the amount of space they take up will eventually be improving per bugs 48926 and 15144; whereas, the sidebar consumes an unconscionable amount of space and AFAIK there are no plans to change this and probably never will be, since the only people who like the sidebar at all are people who like cluttered screens. > My current plan was just to include an extremely large number > of prefs (with only a few turned on by default) and let the > user choose which ones to include via the context menu. Like this plan. > feature is aimed only at developers. I don't see the case > for providing this to millions of end users who would only > be confused by it and don't have a pressing need to be > flipping these values more than once in their lifetimes. True for some preferences, but extremely false for things like Java and Javascript, that *need* to be off to make some pages usable, and those are pages that tend to be viewed mostly by end users, NOT developers. > The fact that these features are useful does not necessarily > mean we need a new toolbar. Computer monitors are > vertical-space-poor and horizontal-space-rich compared to > how people like to read documents. We should avoid taking > more vertical space than is absolutely necessary. A separate issue entirely; see bugs 48926 and 47418, among others. Furthermore, your claim that monitors are rich in horizontal space and poor in vertical space is fairly irrelevant in the light of web browsing; it is no problem to scroll vertically after reading a paragraph; the need to scroll horizontally every single line is *seriously* annoying. Most web pages designed for 800x600 can be viewed comfortably at 800x400 but degrade very ungracefully at 640x480. In summary, Toolbar=good. Sidebar=evil. > A menu would also have to be removed by all > distributors whose target audiences were not > hardcore techies No offense, but you must surely be smoking crack. If you read n.p.m.wishlist (or search Google), you will see Java and Javascript preferences in particular get *regular* requests there for a place on the toolbar, and many of the people making these requests are not sufficiently technically-oriented to comfortably use Bugzilla, let alone "hardcore techies". > This is why I continue to suggest that the best > place for this UI is a sidebar panel. The best place for the sidebar is on another planet. Toolbars also can be easily put away when not needed, and they take a lot *less* space. A *lot* less.

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

as part of the toolbar customization system, which is on the (event) horizon, this bug might get solved. users will be able to create custom toolbars and add hidden features, from other components, or from prefs.

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

The Preferences Toolbar does not install correctly in recent builds. I can't get it to work. Is this just me, some other change to my system, maybe, or can someone confirm that this has bitrotted?

> does not install correctly in recent builds. Oddly, I have it working again in 2001120603; apparently, in addition to restarting Mozilla after installing it, I also had to restart Windows, but now it works. This is really odd, because the same procedures did _not_ get it working in 0.9.6, for example. The only other thing I know about that I've done to Mozilla ad interim is install a silly little plugin that opens the CD-ROM drive. Anyway, I have my prefs toolbar back, and I'm happy, but I fear what will happen next time I upgrade Mozilla...

The solution for this has been out now for seven months. What possible reason can there be not to release it?! I'm for putting the toolbar out now. I'd default it to visible, too. Who doesn't occassionally want to turn off popups or javascript? [A: people who don't know they can turn it off]. I'd say goto and setting of the homepage should be added to this one as choices, since these are truly preferences. I might even hide the personal toolbar if I could have a home button on this one. Another minor suggestions - the context menu of all toolbars should have a "hide toolbar" option.

> The solution for this has been out now for seven months. > What possible reason can there be not to release it?! Read Gerv's comment (#59). I disagree with his reason, but there it is. > I'm for putting the toolbar out now. So vote for bug 111714. > I'd default it to visible, too. I don't frankly care whether the default is hidden or visible. I just want to not have to install it again every time I download a new version, or every time I install the browser on another computer. Actually, when I think about it, the prefs toolbar should probably be hidden by default, on the grounds that people who don't bother to look under View->Show/Hide are unlikely to care whether various preferences are turned on or off (since, indeed, whether toolbars are visible or hidden is in itself a preference, from the user's perspective). Also, the default state should IMO try to be similar in appearance to version 4 browsers (although by that reasoning the sidebar should be disabled by default and the classic theme used by default, so perhaps this reasoning is inconsistent with the develpment team's philosophy). > Who doesn't occassionally want to turn off popups or > javascript? [A: people who don't know they can turn it off]. popups are a bad example (and a separate bug), but there are a lot of people who occasionally want to turn off (or occasionally want to turn on) Java or javascript, and there are a few people who don't usually leave cookies turned on but need for one reason or another to turn them on occasionally. And then there are the few like me who normally leave page colours disabled but want occasionally to turn them on. But I think the largest number of people would mostly want the java and javascript checkboxes. > I'd say goto and setting of the homepage should be added to > this one as choices, Is this really something you want to change with any frequency? Don't most people keep the same homepage for days or weeks or even months at a time? Stuff like that, it's no big deal to drag out the Preferences dialog. The toolbar is particularly nice for stuff you want to change frequently (as in several times a browsing session). > I might even hide the personal toolbar if I could have a > home button on this one. I think changing which buttons are on which toolbar should be reserved for bug 15144. This bug is only about making preference buttons available; navigation buttons are unrelated. > Another minor suggestions - the context menu of all toolbars > should have a "hide toolbar" option. Interesting suggestion, but not related to bug 38521. Please make this comment in a more appropriate location.

In case anyone here hasn't noticed, someone files bug 111714, "Integrate Preferences Toolbar into the main Mozilla tree" a while back, and there has been some talk in that bug about whether or not this should ever be fixed. One of these bugs should probably be marked duplicate or dependant on the other, but since the discussion seems to have moved over there, you may want to move your votes and CCs as well. Aaron

I don't think bug 111714 is a duplicate of this bug per se, but it certainly should be considered dependent on this bug.

Taking. It doesn't look like this is actually going to get in, unless it is done so as part of bug 49543. However, I would be willing to turn my xpi addon into a patch of the occasion arises. See comments in bug 111714.

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

Bug 131518 is a RFE to put freq prefs into the main tree and has nothing to do with toolbars or sidebars.

Instead of calling it the "Preferences Toolbar", why not give it a more fancy name, such as the "Power Toolbar" for power users. That would make it attract more hackers! :)

adding self to cc list

I hate toolbars and also the sidebar because they waste a lot of display area. I prefer menus with command keys. i.e. ctrl-J / cmd-J could be used to toggle JavaScript on and off. The menu item for this feature could be "Tools" -> "Web Development" -> "JavaScript on" / "JavaScript off"

Yep, toolbars as in Microsoft profucts are senseless. Although, _good_ toolbars (see CorelDraw!'s Property Bar) have an obvious advantage of not only letting you configure many switches at once without stumbling through menus, but also letting you see the status of multiple switches at a single glance. Although, there definitely SHOULD be keyboard shortcut for each of those settings.

Aaron, Would it be possible to modify your toolbar xpi to include the ability to hide/show the toolbar by using a hotkey? (I'm thinking about F12, which is currently not used for anything else). I'm asking for this because while I could "minimize" the toolbar with a single click, it still takes too much vertical space (even while I'm running at 1024x768) during normal browsing, so it would be MUCH nicer being able to press F12 to bring it up, change options, press F12 again and hide it. Tell me what you think. Regards Fernando

That makes much sense. But then, why not put it in the sidebar? Can a sidebar tab do this, or does it not have enough permission?

Is it possible to hide a sidebur with a single hotkey? Usually, sidebars occupy much more screen space (150*700) than a toolbar (1024*40).

You you pull down you View -> Show, you'll see that the sidebar has F9 as its hotkey for going away.

Reply to comment#81: Yes, F9 hides/shows the sidebar. And in mozilla 1.0rc2/netscape 7.0rc1 and higher, pressing [F11] toggles between normal and "full screen" mode (a la IE). Very, very nice. That's why I think adding a hotkey to show/hide the preferences toolbar using F12 would be great, as F12 is currently not used for anything else. And about the idea of making it a sidebar instead of a toolbar, I think it was discussed before, but anyway my $.02 is that sidebars are great for what they do best: displaying customized web content and/or xul applets like jabberzilla etc. I don't think it would be nice to "pollute" the sidebar with browser preferences. In other words, I don't think I'd like to see browser configuration dialogs (or toggles) moving from the browser interface into the sidebar. I'd vote for leaving it as a toolbar easily hidden by pressing F12 when not used. Just my $0.02 Fernando

I believe F12 is used to open/close the cd rom tray on Mac OS X.

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

I have hooked up F8 as the prefbar show/hide key, because it isn't use by mozilla or any OS that I know of. If there are issues with the F8 key, please enlighten me...

If you want your shortcut key to work on Mac (or if you want to keep Mac people from flaming you), don't choose F8. Function keys are generally reserved on Mac for user programmability. Check the page at http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html to find available keys, and get back to us. Also, the FAQ for choosing a key is at http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html

I still think it has to be an F key. The whole point of having an accell for this is so that one can access it with one click. I think an order of magnitude more people are going to want to quickly show and hid the prefBar then want to quickly show and hide the sidebar, and yet the sidebar has an F key. (Even on the Mac, as far as I know.) If we assign this Ctrl+Shift+H it's not going to be much of an improvement from View->Show/Hide->Preferences Toolbar.

Comment #88 wrote > If we assign this Ctrl+Shift+H it's not > going to be much of an improvement from > View->Show/Hide->Preferences Toolbar Actually Ctrl+Shift+H is short for Go->History on MacOS X. So, you don't want to use that shortcut. Also, I *never* use Go->History, and I *frequently* use Ctrl+Shift+H so at least in my opinion, a three-key keystroke is *much* better than a menu item, even when that menu item is at the root level of its menu. So, I would disagree with your claim that a 3-key keystoke is not much better than a menu item. > I think an order of magnitude more people are going to want > to quickly show and hid the prefBar then want to quickly > show and hide the sidebar, Just curious, but how do you arrive at that estimation? In my experience, the sidebar is used by most mozilla users, while the prefs toolbar is used only by "geeks". Most users don't understand their prefs well enough to want to muck with them. I know many many users who use the sidebar regularly and show/hide it because it takes up a fair chunk of screen. Some folks are web developers and have reference materials in their sidebar. Many more folks hold search results in their sidebar. An intermediately-sized group use their bookmarks and/or history from their sidebar as a surrogate start page. These users show/hide their sidebar as an integral part of their web browsing. I know less than ten users who use the prefs toolbar (counting myself). They use it for specific sites where their normal prefs are not ideal. Occasionally they find a new site where they need to use it. The toolbar is small enough that I have not heard one complaint from any of these users about the space it takes up. I think that even if there were a keystroke to show/hide the toolbar, most of these users would just leave it visible all the time. If they did show/hide it, I don't think they would do so more than they do with the sidebar (with the exception of one user in the toolbar-using group who doesn't use the sidebar at all). > and yet the sidebar has an F key. > (Even on the Mac, as far as I know.) Confirming for you: yes, even on the mac. ...but I'm still thinking more users show/hide the sidebar with greater frequency than would show/hide the prefs toolbar. I'd be curious to hear why you think otherwise. Is this based on your own browsing habits, or on observation of other users (what sort of users were they?), or on a usability study? > I still think it has to be an F key. There are only so many F keys. Assuming mozilla has the "right" to occupy those F keys (mac tradition is that mozilla should leave those to the user who knows better what 15 things they find most important), are you so certain that your feature is more important than any other 15 features? > The whole point of having an accell for this > is so that one can access it with one click. (keystroke, I'm assuming you meant, rather than click) Hmmm... is that true of *every* accell, or just this one? If *every* accel, then we're going to run out of keys. If just this one, why is it that *this* feature's accel needs to be single-keyed, but others do not? Looking at what's available, I'd suggest control-T or control-J. Personally, I like control-J left pinky to control, index finger on home row hits J. very easy and comfortable (more so than most F keys, for me) I ususally want to turn on/off _J_ava or _J_avaScript control-T is less ideal for me because it's harder for my right pinky to get to the control key (that could just be me), but I like the T character as standing for "turn on/off" "toggle" or even "toolbar". What do you think? -matt

Dude, where have you been? Download a recent Mozilla, press Ctrl-T, and realise that you really can't have it for the Preferences toolbar ;-) Gerv

in the language of http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html that's accel-T. On my mac, that's command-T. control-T doesn't do anything on my machine. -matt

Re: comment 88 Those of us who can't/don't use high screen resolutions don't have space to give a sidebar. The very first thing I do after create new or migrate profile is F9, and in first pass through prefs untick "open search results in sidebar".

> > I think an order of magnitude more people are going to want > > to quickly show and hid the prefBar then want to quickly > > show and hide the sidebar, > Just curious, but how do you arrive at that estimation? In my experience, the > sidebar is used by most mozilla users, while the prefs toolbar is used only by > "geeks". Most users don't understand their prefs well enough to want to muck Obviously, I was referring to only those users who had the prefbar installed (and was based on the hundred or so feedback emails I've been sent regarding the prefbar and what people want out of it). Since the prefbar is not likely to be in the default builds any time soon, any shortcut key assigned to it won't do anything to users who don't have it on their machine. If we're talking about actually checking this in, well then that's a whole different story... The reason I want the prefbar to have a one key shortcut is because of the way people use (or will use) the prefbar. Nobody wants to have to give up the vertical screen space to have it open all the time. Instead they want to say "Oh look, this site has an unreadable color scheme. Open prefbar. Turn of colors. Close prefbar." or "Oh look, this site blocks non-IE browsers. Open prefbar. Change user agent to IE. Close prefbar." and get on with their life. The whole thing wouldn't last more than six seconds. If mac users really do value their F keys that much, they don't have to use the prefbar. My guess is that any mac person who cares enough to install this thing is going to find it much more useful than whatever "user macro" he could have otherwise assigned that key. Aaron

As for this whole function key debate (mpt is trying to force caret browsing hotkey to something other then F7, and now the Tools menu looks awful because the hotkey name is almost longer then what it actually does), if MacOS is so silly as to bind TWELVE keys on their keyboard to global OS functions, so be it. But these keys on Windows and Linux are intended for APPLICATION use. If we end up with ctrl-shift-something for stuff like this that's important to be able to hit quickly, I'd be upset. Mac can have the crummy hotkey. Give Windows and UNIX users something reasonable. What about having shift (or alt, ctrl, or command) + numbers do on mac what F keys do on other OSes? Alt-1 through Alt-= is a much better set of 12 hotkeys then forcing EVERYONE to use ctrl+shift+alt+meta+hyper+p for pref bar. I can hit "alt-e, e" pretty damned quick. If pref bar isn't super easy to pop up and down, it may as well not exsist.

Um, this bug is in no way dependant on bug 153645. Removing dependancy.

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

Count me among the "frequent pref changers" who want to do preference changing while doing regular (ie non-developer) browsing. I want to turn off pop-ups as the default and then turn them on briefly on a page that needs them in order to pop up a dialog that I really want to see. Also, on a page that has fonts that are too small or background colors too similar to the font colors (what brain disorder afflicts the web designers who do that?) it would be helpful to be able to _rapidly_ change some settings. So this is not just a feature for developers. I also support URL-specific preferences. It would be good if the URL specification supported some wild carding of URL patterns. Like *.mysite.com or www.mysite.com/anythinghere/* to specify areas of sites that should have particular preferences. Also, "apply preference change to current page only" would allow one to avoid having to reverse the preference when done viewing a page. Another idea: Right click on a page and choose an option called "Alternative Preferences". Moz would then pop up a list of user-defined named preference sets (a few sets could be included). Then click one one of them to choose which preference set to apply to the current page. What is important here is that the preference sets should be able to be incomplete lists of preferences. That way one could define a set that just changed background color without having to copy over all the other setttings and therefore without having to maintain the preference sets in sync with each other for all the prefs for which they have common values. So: 1) Named preference lists. 2) Preference lists that are subsets of all possible preferences. 3) Assignable preference sets to A) Current page B) Current Tab C) Current Window D) URL Patterns E) Permanent Global (ie assign a named preference list to the main default preference list) 4) Right click choice to choose named preference list. A nice twist here would be the ability to have the choices be cumulative since the preference lists would be subsets. 5) Right click choice to revert to default preference list. 6) Save current set of preferences as default.

this is purely an issue of sematics i have with the summary of this bug, because i agree with some of the proposed ideas, but refering to it as a 'preferences bar' for me, defeats the purpose and concept behind preferences. sorry if i am being a picky UE guy, but if we called it something like 'advanced user bar', 'custom toolbar' or 'formatting bar' i'd feel better. because if there really are features out there hiding in prefs, they should be surfaced more easily, and we shouldn't be calling them prefs anymore. as i mentioned earlier, toolbar customization would solve this, because one of the plans is to offer pre-packaged custom bars that would be available for each component. in which case this bug could be more about what one of the 'default custom user bars' might look like for browser. so imagine a dedicated content view (like in mac ie) for toolbar customization that would allow you to edit your current toolbar, or choose from a pre-arranged, advanced set of toolbars which cater to different types of users.

this is purely an issue of sematics i have with the summary of this bug, because i agree with some of the proposed ideas, but refering to it as a 'preferences bar' for me, defeats the purpose and concept behind preferences. sorry if i am being a picky UE guy, but if we called it something like 'advanced user bar', 'custom toolbar' or 'formatting bar' i'd feel better. because if there really are features out there hiding in prefs, they should be surfaced more easily, and we shouldn't be calling them prefs anymore. as i mentioned earlier, toolbar customization would solve this, because one of the plans is to offer pre-packaged custom bars that would be available for each component. in which case this bug could be more about what one of the 'default custom user bars' might look like for browser. so imagine a dedicated content view (like in mac ie) for toolbar customization that would allow you to edit your current toolbar, or choose from a pre-arranged, advanced set of toolbars which cater to different types of users.

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

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

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

there's the prefs toolbar XPI on xulplanet and adding buttons to diable CSS and Plugins shouldn't be that difficult to be added, or? So what's the problem with this?

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

http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar Cool feature, i mentioned this to an opera user he laughed and in Opera pointed to: File, Quickprefs F12 with submenu of checkbox menu items. Always got to do comparisons when designing GUIs. i asked what the F12 shortcut was for and it pops a context menu under the current cursor position. A quick scan of the comment already seem to want to use F12 for this (although ill bet there are window managers and system programs that want the F keys and that applications are supposed to avoid using them). I dont have opera so sorry i cannot do a screenshot for you. I assume it was the latest version of Opera. This seems to me like probably the best interface to solve this problem. (biased: i never use the sidebar). Maybe there is another bug about a differnt inteface solution to this problem or maybe this bug should have it summary changed to be more generalised? I had considered doing something with javascript bookmarks (afaik you can change pref using a javascript protocol bookmark aka bookmarklets) so that i could simply add these items to my Personal toolbar, but that would not allow me to have checkboxes. (Sorry if any of this is redundant, i did quick scan of the comments but i dont have time to carefully read them all and i really wish there was some way for maintainers to summarise bug reports, 100+ comments is really a bit too much).

http://www.squarefree.com/bookmarklets/zap.html did a quick search on this page for the word zap so i am geussing no one mentioned these useful bookmarklets (again sorry if this is redundant) add them to you bookmarks and your personal toolbar folder as an alternative solution to this problem. the URL field was empty so i add the link there too, feel free to change it, probably be better if the a link to that other toolbar was there.

Sorry, for being redundant, but using a popup like Opera's Quick Preferences really is the *only* thing that makes sense. A popup has more space for prefs than a bar, it doesn't take up space during normal browsing. In Opera I press F12 to call the popup and click on the Javascript entry and I'm done. Besides, a menu is more flexible than a bar because it can not only have toggles but also radio button groups. Opera uses one in Quick Prefs to select the User Agent it will present to the server. Very useful.

I believe F12 is used in OS X to eject the CD ROM. Unforunately, it's not that easy to come up with keyboard shotcuts these days. However, whatever we do, we will need some kind of keyboard shortcut for quick prefs.

Prefs pop-up dialogs and shortcuts: Well, another way to make it possible to bring up the Prefs dialog would be with a mouse right click (or whatever the equivalent is on Mac) to bring up a list of options over a window. Right now right click does bring up a list of options. Just add a Quick Prefs entry to that list. That'd be really helpful because browsing is a very mouse-intensive activity and so most people tend to be mousing when browsing. BTW, I'd love to be able to right click over an image and have one of the choices on that pop-up be "Stop animated play" in order to stop some flashing icon from flashing. In other words, a few of the really common prefs changes (eg stop an animated image or stop all Javascript on this page) ought to be avaiable without even having to go as far as bringing up the full Commonly Used Prefs dialog box.

With the release of Mozilla 1.1 (OS/2), the "popups" portion of the preferences toolbar has stopped working for me. It worked fine in the development versions. Anyone else?

I just uploaded the update to my Preferences Toolbar at http://www.xulplanet.com/downloads/prefbar/. I think it is a big improvement over the original. Everybody go download it and tell me what you think (over email, so we don't make this bug any longer than we have to.) Aaron

Link to screenshot of Opera6 Quick Prefs menu http://matrix.netsoc.tcd.ie/~horkana/dev/Opera6-QuickPrefs.png just the menu on its own, it is located under File, Quickprefs. If you were to do something similar in mozilla it would make sense to put it under Edit beside Preferences...

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

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

> Nobody wants to have to give up the vertical screen space to have it open > all the time. Just for the record, I leave it open all the time, and doing otherwise seems silly to me, because I use the thing so often... it is more important to me than the personal toolbar (even though I use that extensively also) and the tiny amount of space it takes up is worth less to me (by a fair margin) than the time that would be required to turn it on and off all the time. I could live with a toplevel menu, but something buried underneath Tools->Web Development or someplace like that would be an inadequate substitute. The sidebar, as I said, is Not For Me. The toolbar is the ideal solution. Since it does not look as though the toolbar will be accepted into the main tree, even as an optional package turned off by default, how hard would it be to get it to install into the user's profile chrome, so that it wouldn't have to be redownloaded every single upgrade?

Not sure if this is the right place to report this, but: The "Kill flash" button does not work on some pages, notably the flash advertising at http://linuxtoday.com/.

Not sure if this is the right place to report this, but: The "Kill flash" button does not work on some pages, notably the flash advertising at http://linuxtoday.com/.

See bug #258881, which requests that PrefBar be incorporated as a standard browser feature. See also the corresponding Mozdev 7670 at <https://www.mozdev.org/bugs/show_bug.cgi?id=7670>.