Open
Bug 38521
(prefbar)
Opened 25 years ago
Updated 16 years ago
Preferences Toolbar, for most commonly used prefs
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
NEW
People
(Reporter: mpt, Unassigned)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file)
(deleted),
image/gif
|
Details |
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
Comment 1•25 years ago
|
||
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")
Comment 2•25 years ago
|
||
Then again, support for URL-by-URL prefs (is this landing soon? or ever?) would
resolve the case I just mentioned
Comment 3•25 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Reporter | ||
Comment 4•25 years ago
|
||
Reopening and setting milestone to Future. LATER is deprecated.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: --- → Future
Comment 6•25 years ago
|
||
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>.
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Interesting, marking as future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
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".
Comment 12•24 years ago
|
||
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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.
Reporter | ||
Comment 15•24 years ago
|
||
*** Bug 42658 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 16•24 years ago
|
||
> 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).
Keywords: helpwanted
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
>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.
Comment 20•24 years ago
|
||
if you don't mind implementing a sidebar too for now, that'd be great, i think
there's a separate bug for it.
Comment 21•24 years ago
|
||
A toolbar is less intrusive: you can keep it on all the time without taking away
much space from content.
Comment 22•24 years ago
|
||
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
Comment 23•24 years ago
|
||
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]
Reporter | ||
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
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...
Comment 28•24 years ago
|
||
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
Comment 29•24 years ago
|
||
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
Comment 30•24 years ago
|
||
OK, fair enough. I'm convinced. The prefs toolbar is not the place for this
function, if it is indeed necessary. :-)
Gerv
Comment 31•24 years ago
|
||
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).
Comment 32•24 years ago
|
||
That's a different bug - bug 17199.
Gerv
Reporter | ||
Comment 33•24 years ago
|
||
Making this toolbar customizable should be filed as a separate RFE depending on
this one.
Comment 34•24 years ago
|
||
>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. ***
Comment 36•24 years ago
|
||
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).
Comment 37•24 years ago
|
||
*** Bug 83021 has been marked as a duplicate of this bug. ***
Comment 38•24 years ago
|
||
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).
Comment 39•24 years ago
|
||
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"?
Reporter | ||
Comment 40•23 years ago
|
||
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.
Assignee: mpt → blake
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Comment 41•23 years ago
|
||
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)
Comment 42•23 years ago
|
||
*** Bug 89297 has been marked as a duplicate of this bug. ***
Comment 43•23 years ago
|
||
*** Bug 90309 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
*** Bug 20826 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
*** Bug 93604 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
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
Comment 47•23 years ago
|
||
Comment 48•23 years ago
|
||
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.
Comment 49•23 years ago
|
||
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.
Comment 50•23 years ago
|
||
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
Comment 51•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
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
Comment 53•23 years ago
|
||
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.
Comment 54•23 years ago
|
||
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
Comment 55•23 years ago
|
||
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.
Comment 56•23 years ago
|
||
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.
Comment 57•23 years ago
|
||
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?
Reporter | ||
Comment 58•23 years ago
|
||
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.
Comment 59•23 years ago
|
||
> 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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
Comment 60•23 years ago
|
||
I suggest an obvious solution to getting people's attention to cool-addons with
a new default installed Sidebar for "Mozilla Add-ons"..
Comment 61•23 years ago
|
||
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
Comment 62•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 63•23 years ago
|
||
*** Bug 108380 has been marked as a duplicate of this bug. ***
Comment 64•23 years ago
|
||
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.
Comment 65•23 years ago
|
||
*** Bug 112421 has been marked as a duplicate of this bug. ***
Comment 66•23 years ago
|
||
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?
Comment 67•23 years ago
|
||
> 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...
Comment 68•23 years ago
|
||
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.
Comment 69•23 years ago
|
||
> 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.
Comment 70•23 years ago
|
||
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
Comment 71•23 years ago
|
||
I don't think bug 111714 is a duplicate of this bug per se,
but it certainly should be considered dependent on this bug.
Blocks: 111714
Comment 72•23 years ago
|
||
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.
Assignee: blaker → kc7gza
Status: ASSIGNED → NEW
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 73•23 years ago
|
||
*** Bug 131518 has been marked as a duplicate of this bug. ***
Comment 74•23 years ago
|
||
Bug 131518 is a RFE to put freq prefs into the main tree and has nothing to do
with toolbars or sidebars.
Comment 75•23 years ago
|
||
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! :)
Comment 76•23 years ago
|
||
adding self to cc list
Comment 77•23 years ago
|
||
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"
Comment 78•23 years ago
|
||
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.
Comment 79•22 years ago
|
||
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
Comment 80•22 years ago
|
||
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?
Comment 81•22 years ago
|
||
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).
Comment 82•22 years ago
|
||
You you pull down you View -> Show, you'll see that the sidebar has F9 as its
hotkey for going away.
Comment 83•22 years ago
|
||
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
Comment 84•22 years ago
|
||
I believe F12 is used to open/close the cd rom tray on Mac OS X.
Comment 85•22 years ago
|
||
*** Bug 122007 has been marked as a duplicate of this bug. ***
Comment 86•22 years ago
|
||
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...
Alias: prefbar
Comment 87•22 years ago
|
||
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
Comment 88•22 years ago
|
||
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 89•22 years ago
|
||
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
Comment 90•22 years ago
|
||
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
Comment 91•22 years ago
|
||
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
Comment 92•22 years ago
|
||
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".
Comment 93•22 years ago
|
||
> > 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
Comment 94•22 years ago
|
||
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.
Comment 95•22 years ago
|
||
Um, this bug is in no way dependant on bug 153645. Removing dependancy.
No longer depends on: 153645
Comment 96•22 years ago
|
||
*** Bug 155450 has been marked as a duplicate of this bug. ***
Comment 97•22 years ago
|
||
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.
Comment 98•22 years ago
|
||
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.
Comment 99•22 years ago
|
||
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.
Comment 100•22 years ago
|
||
*** Bug 158452 has been marked as a duplicate of this bug. ***
Comment 101•22 years ago
|
||
*** Bug 158452 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 102•22 years ago
|
||
*** Bug 111911 has been marked as a duplicate of this bug. ***
Comment 103•22 years ago
|
||
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?
Comment 104•22 years ago
|
||
*** Bug 160311 has been marked as a duplicate of this bug. ***
Comment 105•22 years ago
|
||
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).
Comment 106•22 years ago
|
||
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.
Comment 107•22 years ago
|
||
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.
Comment 108•22 years ago
|
||
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.
Comment 109•22 years ago
|
||
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.
Comment 110•22 years ago
|
||
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?
Comment 111•22 years ago
|
||
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
Comment 112•22 years ago
|
||
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...
Comment 113•22 years ago
|
||
*** Bug 170956 has been marked as a duplicate of this bug. ***
Comment 114•22 years ago
|
||
*** Bug 172599 has been marked as a duplicate of this bug. ***
Comment 115•22 years ago
|
||
> 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?
Comment 116•21 years ago
|
||
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/.
Comment 117•21 years ago
|
||
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/.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•17 years ago
|
Assignee: aaron → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla → guifeatures
Target Milestone: Future → ---
Comment 118•16 years ago
|
||
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>.
You need to log in
before you can comment on or make changes to this bug.
Description
•