Closed Bug 205011 Opened 21 years ago Closed 17 years ago

Make search bar/box resizable

Categories

(Firefox :: Search, enhancement, P2)

2.0 Branch
enhancement

Tracking

()

VERIFIED DUPLICATE of bug 267831
Firefox 2 beta1

People

(Reporter: skotten, Assigned: mozilla)

References

()

Details

(Whiteboard: Workaround in comment #41 [swag: 2d])

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030429 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030429 Mozilla Firebird/0.6

I have made a new config-property to make the search-bar resizable:

// ---------------------------------------
// search-bar resize hack
var barWidth;
barWidth =
gPrefService.getComplexValue("browser.startup.searchwidth",Components.interfaces.nsIPrefLocalizedString).data;
var searchBar = document.getElementById("search-bar");
searchBar.setAttribute("width", barWidth);
// ----------------------------------------

The patch should be added inside browser.js (browser.jar archive)

Tested with Phoenix 0.6


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Severity: normal → enhancement
You have to create a new string called "browser.startup.searchwidth" in
about:config in order to make it work. The value is the number of pixels the
search should be wide.
Search bar can easily resizable using userChrome.css without any changes.
#search-bar { width: 30em !important; }

suggest wontfix
If the search bar is made resizable from within the UI then would logic not
dictate that the location bar be the same way as well? As it stands, the default
search bar width is adequate for most people (this is the first I've ever heard
of changing its size) and there is already a userChrome tweak to adjust it.

I think if the tweak in comment #2 is added to the Tips & Tricks page at
Firebird Help we can resolve this bug as wontfix...
*** Bug 206065 has been marked as a duplicate of this bug. ***
David has added this to the Help site:
http://texturizer.net/firebird/tips.html#app_searchbarsize

Thanks David!

-->WONTFIX
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Taking QA Contact
QA Contact: asa → bugzilla
VERIFYING obvious WONTFIX bugs.  Filter on firebirdWontFix to filter these bugs.
 I skipped a few that I'm unsure about from their summary and will manually go
through them.
Status: RESOLVED → VERIFIED
*** Bug 239865 has been marked as a duplicate of this bug. ***
Why is this an "obvious wontfix"? Surely it's simple UI logic that we should
allow resizing of these elements without userChrome.css workarounds. I've seen
people asking for ways to resize the search/location bar plenty of times on
MozillaZine's forums, and the sheer majority of these people are amazed at the
workaround required. To me, this is an obvious omission, not an obvious wontfix.
Please will you reconsider?
Flags: blocking0.9?
*** Bug 243072 has been marked as a duplicate of this bug. ***
I'll second Ben  Bassons request, its not exactly an 'obvious wontfix'.

It may sound dumb, but this is a really killer feature in Safari that I find hard to live without.

For me the search bar is just too small, i'm certain I'm not alone.

See bug 243072
Sorry for the new email folks, but just wanted to add another comment.

As I mentioned in the comments in bug 243072, I think the size should be able to be said on the fly. IE, 
not have a preference for it, but rather a little handle that you can drag to the left/right like in Safari, 
which shrinks/expands the search/url fields.

Thanks again,

David
*** Bug 243406 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Search bar can easily resizable using userChrome.css without any changes.
> #search-bar { width: 30em !important; }
> 
> suggest wontfix

"easily", "userChrome.css" - are you kidding?
*** Bug 248350 has been marked as a duplicate of this bug. ***
I third the recommendation that this bug be fixed.  The search bar should be
resizable with some minimum size (i.e. the current size will do).  Please
reconsider.
I figured out how to make the search bar resizable.  In the browser.jar there is
a  file content/browser/browser.xul.  In it you'll find an entry :

<toolbaritem id="search-container" align="center" title="&searchItem.title;"
class="chromeclass-location">

Change it to the following:

<toolbaritem id="search-container" align="center" flex="1000"
title="&searchItem.title;" class="chromeclass-location">

And then repackage your browser.jar.  Note that this will make your URL bar and
your Search bar compete for screen real estate.  I solved this by making my own
toolbar (named "Search" naturally) and putting the Search control in that bar. 
I also put in some other buttons that I rarely use but might find useful (like
"Open a new tab", "History", etc).

Regards,
Jeff Schiller

Regards,
Jeff
Of course you can also enable history for the search bar by adding:

enablehistory=true

Regards,
Jeff
*** Bug 249457 has been marked as a duplicate of this bug. ***
Hm this ir realy a bad idea to not make this simple fix for simple people.
Requiring them to edit some file and do omething they don't understand is very
very unfriendly.
Flags: blocking0.9?
My Dad/Mom should be able to drag and resize or even drag and drop this item
onto the menu bar or do any such customization with the mouse. Can't expect them
to be editing chrome files.
When the Customize Toolbars sheet is active, hovering over the left or right
edge of the search textbox should give an EW resize cursor.

Reopening.  The patch in comment 0 was correctly WONTFIXed, but I haven't heard
any arguments against making the search bar resizable in the UI.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Summary: Search-bar resize feature Patch → Make search bar resizable in Customize Toolbars mode
(In reply to Jesse Ruderman, comment #22)
> When the Customize Toolbars sheet is active, hovering over the left or right
> edge of the search textbox should give an EW resize cursor.

I agree, but I hope your comment doesn't imply that customizing the size
on-the-fly (as in Safari) is out. I find this method more discoverable and
handier than having to go through the Customize Toolbars sheet every time the
Search bar width doesn't fit the search string.

Prog.
*** Bug 258591 has been marked as a duplicate of this bug. ***
*** Bug 262421 has been marked as a duplicate of this bug. ***
Assignee: hyatt → bugs
OS: Windows XP → All
Hardware: PC → All
As per comment 14 userchrome.css changes are hardly easy for a novice. It took
me a while to find the correct syntax for the file (the Firefox tips didn't
work), and i'm not a novice.

The Search Bar, and probably also the Location Bar, should be resizable.
Especially as, IMHO, the search bar's currently too small. It would also be
useful if the Search Bar had history enabled (or at least optionally).
Maybe an easy solution for 1.0 could be to increase the default Search Bar size.
That would (probably) keep most users happy, especially newbies.
I quite agree. It is ridiculous not to fix this. I am not a computer nerd and
editing Chrome files took me hours before I could find the info to do it
correctly. There's no reason not to make the location and search bars resizable
and even movable with the mouse, as they are in IE. For instance, I have all the
screen real estate that is to the right of the File, Edit menu bar. On IE I
could move the location bar to that bar and make the lower bar disappear,
gaining more space for browsing! I hate to say anything nice about IE, but in
that regard it is still superior to Firefox.
Marcel7
> On IE I could move the location bar to that bar and make the lower bar
> disappear, gaining more space for browsing! I hate to say anything nice about
> IE, but in that regard it is still superior to Firefox.

Are you on crack?  Firefox can do this as well.  And it is completely irrelevant
to this bug.
The toolbar is far more customisable than in IE, but the Location and Search
bars are fixed width.
This won't change for 1.0, but the default search bar size could be changed as a
workaround.
Whiteboard: workaround: comment 2
I don't think Comment 2 is a suitable workaround for end users/newbies who will
immediately notice this problem.

Perhaps if it was configurable via a pref then it would be okay.
Comment 2 doesn't work on Mac OS X with Firefox 1.0PR as per bug #267831 .
I don't understand why the resizing can't be done with the mouse. I don't have 
that much patience with modifying chrome files. Also the Toolbar and menu bar 
should be made resizable/moveable/dockable on any place. For example I should 
be able to place the toolbar on the menu bar, resize the address box and 
search box. (For example look at Avant Browser)

All this should be done with the help of the mouse and not with chrome files.
I am somewhat amazed that this group continues to want users to delve into
config files for their browsers.  We allow font size changing and a slew of
toolbar customizations without requiring a text editor; why make this arbitrary
distinction for the box resizing?  After looking the
http://dragtotab.mozdev.org/ extension and the code mentioned here, the changes
seem pretty small given the (large to me) benefit to the user.  BTW, just me,
but on the 3 novice users' machines on which I have installed Firefox, the first
question they ask upon using the search box is "How do I make it bigger?".
*** Bug 269189 has been marked as a duplicate of this bug. ***
It shouldn't be something you put onto the toolbar, it should just be a cursor
change when your cursor is near the start/end of the box, letting you know that
it can be changed.
Just see how many bugs have been marked as duplicate of this bug, developers
should understand that editing chrome files is not a good idea for such a simple
requirement.
The work around for this no longer works, at least as of Firefox 1.0.

Here is how the thing should work IMHO:

The URL bar and the search bar should both expand to take up all available space
in the given toolbar, after buttons have taken theirs. (Currently this is not
the case).
Then there should be a little horizontal adjustment dragger thing that can be
dragged left and right in order to increase/decrease the allocated space for
these two input boxes.

Please look at this. It is driving me _utterly insane_ now that the work around
no longer works. Most of my searches are rather long (ie
'site:some.domainoranother.com something in a reference manual'), and it's just
a nightmare trying to do it in this tiny little box.

Thanks heaps!

David

PS - perhaps remove the workaround comment from the whiteboard, and s/in
Customize Toolbars mode// in the Summary.
The following workaround works for me:
1. Install the resize searchbar extension
2. add 
     #search-container {
       -moz-box-flex: 800 !important;
     }
    to userchrome.css
3. optionally move the search bar to the right of the help menu in the menubar.
it should then fill the spave between 'help' and throbber.

If step 1 is omitted, step 2 is useless.
Alternatively create UserChrome.css in profile-directory\chrome with the
following contents:

-------------------------------

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
/* set default namespace to XUL */

#search-container
{
width: 20em;
}

#searchbar
{
width: 20em;
} 

-------------------------------

Change 20em to the required size. Then restart Firefox.
#search-container, #searchbar {
   -moz-box-flex: 220 !important;
}

works fine for me. As does the Resize Search Box extension:
https://update.mozilla.org/extensions/moreinfo.php?application=firefox&id=349&vid=1080
Whiteboard: workaround: comment 2
Whiteboard: Workaround in comment #41
All this should be done with the help of the mouse and not with chrome files.
*** Bug 274378 has been marked as a duplicate of this bug. ***
Don't you think a resizing widget like that extension is the way to go?
(In reply to comment #44)
> Don't you think a resizing widget like that extension is the way to go?

I think a combination of both would be the best solution:
The resizing widget should only be visible /useable in Customize Toolbars mode,
cause nothing else is moveable in normal mode. I think that should fit the best
with the users expectations.
(In reply to comment #45)
> (In reply to comment #44)
> > Don't you think a resizing widget like that extension is the way to go?
> 
> I think a combination of both would be the best solution:
> The resizing widget should only be visible /useable in Customize Toolbars mode,
> cause nothing else is moveable in normal mode. I think that should fit the best
> with the users expectations.
I disagree.  The user should be able to resize the search bar at any time. 
That's the whole point of this bug - to allow the user to *easily* resize it on
the fly as they see fit.  If I have to go into "customize toolbar" mode each
time I want to resize the search bar because I have a long query string, it's
just as useless as it currently it.

The "Resize Search Box" extension is almost perfect.  The only problem with the
extension is that it does some strange things occasionally when it's moved
around to various places in combination with other toolbar controls.

The last issue I have with the search box in Firefox is that it needs an
accelerator key so I can immediately jump to it via the keyboard (just like
Ctrl+L goes to the Location bar).
(In reply to comment #46)
> I disagree.  The user should be able to resize the search bar at any time. 
> That's the whole point of this bug - to allow the user to *easily* resize it on
> the fly as they see fit.  If I have to go into "customize toolbar" mode each
> time I want to resize the search bar because I have a long query string, it's
> just as useless as it currently it.

I guess there's pros and cons to both methods. Personally i'd prefer a fixed
search box size and to change it through customise toolbars.

(In reply to comment #46)
> The last issue I have with the search box in Firefox is that it needs an
> accelerator key so I can immediately jump to it via the keyboard (just like
> Ctrl+L goes to the Location bar).

Ctrl+K
Not sure if there's a vote going on here, but just in case there is:
I'm with Rick Alther (comment 46) on this.
(In reply to comment #47)
> I guess there's pros and cons to both methods. Personally i'd prefer a fixed
> search box size and to change it through customise toolbars.
Why would you want to have to go through the additional steps in order to resize
it?  If you don't feel like resizing it, then you don't have to. I don't see how
this gets in your way.

I'm missing your argument here.  Where is the downside of having it resizable
whenever you feel like it?

> 
> (In reply to comment #46)
> > The last issue I have with the search box in Firefox is that it needs an
> > accelerator key so I can immediately jump to it via the keyboard (just like
> > Ctrl+L goes to the Location bar).
> 
> Ctrl+K
Thanks!  Of course, why it's 'K' is anyone's guess.  Not very intuitive.  
I, too, will weigh in for a resizer that works easily on the fly.  Seems pretty
pointless otherwise and certainly fails to meet the expectations of IE users
accustomed to toolbars that can be altered easily.

Thanks for the Ctrl+K and Ctrl+L keyboard shortcuts.  I know I'm going to get
lots of use out of those.
(In reply to comment #49)
> Why would you want to have to go through the additional steps in order to resize
> it?  If you don't feel like resizing it, then you don't have to. I don't see how
> this gets in your way.
> 
> I'm missing your argument here.  Where is the downside of having it resizable
> whenever you feel like it?
The same argument could be used for moving toolbar buttons on the fly, which
isn't currently possible either.

The reason a separate customise toolbars mode is required is to stop people
inadvertantly resizing the search bar.
How many MS Word's have you seen where the toolbar has been moved accidentally?
I've seen very many.

For me resizing the search bar (or editing the toolbar) is something I do very
rarely. Therefore a separate (and easily accessible) edit mode, as currently
exists, is adequate.
(In reply to Stefan Pukallus, comment #45)
> The resizing widget should only be visible /useable in Customize Toolbars mode,

I'm afraid you're in a minority here. I too find your suggesed solution to be
rather useless. The search bar should be resizeable - just like it is in Safari,
and just like toolbars in other browsers (namely IE6)

> cause nothing else is moveable in normal mode.

Is that so? Bookmark Toolbar links can be dragged around without opening the
Bookmark Manager, and of course you don't need to open any special panel to be
able to resize the browser window or scroll the page. Widgets that *should be*
easily resized should not require any additional UI.

> I think that should fit the best with the users expectations.

It wouldn't fit the expectations of users who switch from Safari or IE, nor
would it fit the needs of anyone who hates needless complexity.

Prog.
IE users can drag their toolbars at any point in time, without a Customise
screen.  Maybe if you want it to work all the time, we should just get rid of
the Customise screen altogether?  That would seem to fit the same UI philosophy.
(In reply to comment #53)
> Maybe if you want it to work all the time, we should just get rid of
> the Customise screen altogether?

This is a fine suggestion for moving buttons which are already in the toolbar to
the desired location (Mac OS X Finder does that), but it won't do for
adding/removing buttons, you need a repository for that - the Customize Toolbar
panel.

Prog.
Since people have different ways of going about it by switching from diffferent
browsers, why don't we make a block of code that tailors to what browser they
came from?  We can get this info by looking at which browser settings they imported.

if (IE){
  // Lock/unlock toolbars option with normal Firefox button repository (not IE's
way of toolbar making)
}
elseif (Safari){
  // Change toolbar config all the time.
}

OR, we could just make the toolbars lockable/unlockable like IE (shudders) as
the default.  Seriously, how many times do you need to resize the Search bar?

Anyway, this seems to be getting a smidge off-topic.  Check comment #36 for an
option.

Dan
(In reply to comment #52)
> (In reply to Stefan Pukallus, comment #45)
> > The resizing widget should only be visible /useable in Customize Toolbars mode,
> 
> I'm afraid you're in a minority here.

Firefox isn't a democracy - the developers will decide whether the search box
should be resizable on-the-fly or only from the Customise dialogue.
(In reply to comment #56)
 
> Firefox isn't a democracy - the developers will decide whether the search box
> should be resizable on-the-fly or only from the Customise dialogue.

And mozilla.org's bugzilla isn't a support forum, [most of] the latest comments
are making this bug useless for real development.
Ideally, search bar should not only be resizable [this user thinks it's obvious
that the default width is too short], but re-locatable as well. WHY should the
topmost [Menu] items use only 1/4 of their allotted horizontal toolbar-space,
when the address bar and search bar are crammed together on the same level? I'd
very much like to see Firefox add the capability of moving either the address
bar or the search bar to the topmost toolbar space, next to the menu items. 
Thanks for your time & attention to detail.
terry b.
(In reply to comment #58)
> Ideally, search bar should not only be resizable [this user thinks it's obvious
> that the default width is too short], but re-locatable as well.

It is "re-locatable" already. You can use the Customize Toolbar dialog to move
the Search bar onto the menu-bar.
-> http://www.mozilla.org/products/firefox/ui-customize.html

Prog.
*** Bug 276645 has been marked as a duplicate of this bug. ***
Please include Resize Seach Box by default, like it is in IE.  Thanks!
I'm voting for an implementation like that of the Resize Search Box extension: 

https://update.mozilla.org/extensions/moreinfo.php?application=firefox&id=349&vid=1080

It's perfect!
(In reply to comment #62)

> It's perfect!

The look and feel is perfect, but for it to be included by default it needs to
be more seemlessly integrated. For example, you shouldn't be able to have the
resizer anywhere but directly to the left of the search box (try moving it to
the right side of the search box and witness some awesome confusion).
(In reply to comment #63)
> The look and feel is perfect, but for it to be included by default it needs to
> be more seemlessly integrated. For example, you shouldn't be able to have the
> resizer anywhere but directly to the left of the search box (try moving it to
> the right side of the search box and witness some awesome confusion).

I still feel the best solution is to make the search bar automatically fill up
all the space that it can on a toolbar leaving enough space for buttons,
separators, etc.  If the Address Bar is on the same toolbar it takes precedence.
 Having to resize the search bar will be a bit of a pain.

I've got it set up that way by modifying browser.jar and classic.jar with the
search bar on its own toolbar with "Add Tab" and "History" buttons and it's
quite nice....
The resizer should only be placable between two resizable elements (e.g. address
bar and search bar, in any order).
(In reply to comment #65)
> The resizer should only be placable between two resizable elements (e.g. address
> bar and search bar, in any order).

I think it's a daft idea to allow the user to place a resizer - users don't
consider a resizer as a separate item. A resizer should just be part of any
resizable elements.

Alternatively, the search bar could be given x% of the width of the location
bar. E.g. the location bar could take up 75% of the available space and the
search bar 25%. I think this would require a change to the way flexibility is
described.
So this bug as been around since 0.6 (that's longer than me - 0.7) and yet you
still can't resize the search bar after 91 votes?
removing impl' detail from summary.
Summary: Make search bar resizable in Customize Toolbars mode → Make search bar resizable
(In reply to comment #68)
> removing impl' detail from summary.

Maybe those summary words were there to avoid duplicates?

Summary was: Make search bar resizable in Customize Toolbars Mode
(In reply to comment #3)
> If the search bar is made resizable from within the UI then would logic not
> dictate that the location bar be the same way as well? As it stands, the default
> search bar width is adequate for most people (this is the first I've ever heard
> of changing its size) and there is already a userChrome tweak to adjust it.
> 
> I think if the tweak in comment #2 is added to the Tips & Tricks page at
> Firebird Help we can resolve this bug as wontfix...

The idea is to have a splitter widget between the location bar and the search
bar.  I have heard complaints about the search bar being to small (especially on
windows). Searching the MozillaZine knowledge base for tutorials on changing the
size of the search bar and diving into the userChrome.css file is not something
I would expect to see my mom doing. This is way beyond the average user's
computer skills. Adding one little dot is not adding much bloat in my opinion.
(In part in reply to comment #70) 
> The idea is to have a splitter widget between the location bar and the search
> bar.

1) There is absolutely no reason to suppose the search bar and location bar will
be adjacent. User comfort and choice of search related extensions with buttons
both make that quite unlikely without undesirable restrictions being imposed.

> Searching the MozillaZine knowledge base for tutorials on changing the
> size of the search bar and diving into the userChrome.css file is not
> something I would expect to see my mom doing.

2) or even anyone at all if FF is to succeed as a popular tool which is capable
of surrounding M$. "Tweaks" are for .... (which is a term in which we don't
believe in the 21st century) but certainly not for enthusiasts (in which we do)

3) If the search bar is extreme left on a toolbar, as should be possible, then
you try having a resizing by drag widget on its left and see what happens!
Widget position should at least take that into account.

4) Whereas FireFox may not be defined by a user democracy (why not?) it would be
a very foolish body that did not pay avid attention to user comfort and
fulfillment. That is not achieved without careful pursuit of and responsiveness
to user reactions and opinion. To say "the devs will decide" assumes that people
who are good at creativity and programming are equally good at people, usage and
ergonomics. That is seldom true all the time and the number of shortcomings in
the UI and even more profound implementations in FF would not be so large and
longstanding if it was.

5) Would those people who casually drop the terms "newbie" and "noob" all over
the place please stop to reflect that, however intended, the words are
disrespectful/patronising/discourteous/rude/insulting and, like other such
discriminatory expressions do not leave the impression of kindly consideration.

6) No, I don't think very much of this thread is spam because I, like other end
users, want to see solutions for us, the users, emerge and not changes made in a
form which derives from a learned discourse on how many angels can dance on the
head of a pin. From my years in mainframe OS support, I *know* that user input
to problem definition and the form of solution is essential. Where else will
that occur if not here? So please read it, don't discard it!

The thing over which we, as users, do have to be very careful is trying always
to stick close to the target so it can be clearly defined and killed as
usefully, efficiently, and as quickly as possible.

With respect, RDL




7) No matter how many times someone says the same thing a different way, it 
doesn't actually increase the priority of the bug record, and merely serves to 
annoy people who are subscribed to the bug record in order to receive real 
progress updates. 
(In reply to comment #72)
> 7) No matter how many times someone says the same thing a different way, it 
> doesn't actually increase the priority of the bug record, and merely serves to 
> annoy people who are subscribed to the bug record in order to receive real 
> progress updates.

Perhaps part of this whole problem is people who imagine they have understood
the meaning of a passage when their reply clearly shows they have not.

1) my previous entry made no attempt whatever to attempt to raise the priority
of this bug, nor did it in any way suggest that was my intention. For that I
simply had to vote, and did.

2) The purpose of the points I made was, in the main, to highlight factors which
I believe should be taken into account when considering the form of any solution
which might be made. For instance, it is clear from some of the contributions,
that some people are not aware that always putting a sizing widget on the LHS of
the bar will make it unusable when the bar is on the extreme left. The point
about search and location bar not probably being adjacent in practice had to be
made since someone was putting forward a request that the solution be made
ignoring that fact ... etc

3) If you believe I repeated what had already been said, I suggest you very
carefully re-read what I wrote. Perhaps the fact that you did not notice any new
input in the comments and you perceived them purely as some kind of silly
pressure to have the priority of the bug raised is evidence of why people are so
anxious to make their wishes explicit. They are afraid that decisions may be
made by people who cannot discern the distinct factors involved from the
end-user (client) point of view.

Just now I *will* say the same thing slightly differently. When someone says
something new and you perceive this as  "someone says the same thing a different
way" and also completely misunderstand the motivation behind what is said, then
the matter under treatment is not receiving proper attention.

4) Moreover, if you believe that the sole purpose of a bug thread is to report
what you call "real progress reports" then you assume that the full nature of a
bug and of its best solution are always already defined and that they are known
by those having the task of amending the code. In cases where the code simply
does not fulfill the specification, then that is tue, but in other cases, since
support is not telepathic, then without consulting enough end-users, that
support often will not know what is best suited for those end-users. If you are
saying that the end-users have no proper place in the process of deriving well
founded solutions and the expression of those interests in order to shape the
solution formation process will simply annoy support workers then something is
very seriously wrong and Mozilla will just end up like any big business with a
"them and us" situation.

"Responsive" is the watchword for successful support.

And since this discussion is, while not spam, unfortunately focussed in one
particular bug which is not the prime locus of the extra problem highlighted I
won't rise to any more mention of it. I made my points about the actual bug and
I let them stand. I hope my more general "points arising" made sense to some
readers.

RDL
> 2) The purpose of the points I made was, in the main, to highlight factors which
> I believe should be taken into account when considering the form of any solution
> which might be made. For instance, it is clear from some of the contributions,
> that some people are not aware that always putting a sizing widget on the LHS of
> the bar will make it unusable when the bar is on the extreme left. The point
> about search and location bar not probably being adjacent in practice had to be
> made since someone was putting forward a request that the solution be made
> ignoring that fact ... etc

If the search bar is made resizable (and, IMHO, the location bar as well), this
DOES NOT mean that the resizable widget is viible 247.  For example, it should,
IMHO, be only visible in "Customize..." mode.  Either we go that route, or go
with a lock/unlock toolbar(s) options.  The unlock option would also allow a
user to move/add widgets.
I have moved three offices (40+ installs) to Firefox and this is a regular
"first look" criticism. Chrome hacks are impractical in small office
environment. Right now I kludge by moving search to menu bar and adding several
icons, e.g. history, print, new tab. Earlier (1.0) I tried using various spacers
and bookmarks but it proved unstable. This is still a kludge but IMO better than
having to add an extension. New users expect to modify appearance at the moment
they are introduced to FF.  

Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 300758 has been marked as a duplicate of this bug. ***
Based upon the large number of votes, the many pleas to add this as core
functionality (for non-technical people), ease to do and just plain common sense
that this should be core functionality...Nominating blocking 1.8b4.

BTW.  A better workaround than comment #41, but, IMHO still unaccepable one is
to use the Resize Search Box extension.
Flags: blocking1.8b4?
1.8b4 is close to being wrapped up, I suspect only critical bugs and regressions
will be considered.  Adding new non-critical features, especially those those
supplied by an existing extension, is ridiculous at this point.
(In reply to comment #78)
Maybe 1.84b4 is to close to be adding functionality to it.  Bryant, Do you think
there is any chance that it could make it into Fx 1.5 if it is not implemented
in 1.84b?
I think this enhancement is an easy one to fix and a very important one to have.
 "How do I make the search box bigger?" is one of the first things Fx newbies
ask.  Most Fx newbies (including my grandmother) don't know anything about
extensions, let alone how to install them or even find the one that they want to
do the job.
Flags: blocking1.8b4? → blocking1.8b4-
I wouldn't know - I'm not affiliated with Mozilla in any way.  I just don't want
Firefox 1.5 to be delayed over and over again just because of last minute "easy
fixes" (hundreds of "easy fixes" is not an easy fix).

As an alternative, you can try making a bug report asking for the default size
of the search box to be larger.  That would involve a single change in the
chrome CSS, so that would most likely be a trivial fix.
The new Yahoo! toolbar also supports this, which is evidence of the wide desire
for it.

Why not simply make it such that, whenever there are two or more elements that
expand to fill the available space, resizers are automatically placed between
them. If one element is moved or removed such that it is no longer bordering
another one, then the resizer should be automatically hidden.

Diagram: f is static, e is expanding, and | is resizer
fffe
fffe|e
fffe|e|e
fffe|e|ef

I understand that this would break if there was a non-resizable element placed
between them, although I don't imagine that this is a common configuration, but
the implementation I suggested above could also be modified such that it occurs
when two or more of these expanding elements are in line with each other, and
the resizers would appear on the edges except the smallest one.

E.g.:
fffe|f|e
Or even (hypothetically to get the idea acros, this would be a really ugly
cluttered interface) ffe|ff|e|e|fff|ef
If it's an easy fix, please write a patch that implements the feature in a
logical and usable way. That, or track down an extension author that is willing
and able to do this.

Realistically, I can't see a reason why this couldn't be added in at any time
before release candidates are produced for Firefox 1.5, it should be low-risk
and should not require l10n additions or changes.

There's no need to further comment in this bug unless you are contributing code
or relevent information that will help to get this bug fixed. 
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
As told so many times in the comments above: this is really a missing feature. 

When I have a look at the main product page of Firefox (
http://www.mozilla.org/products/firefox/ ), I read this:

"S, M, L or XL—It's Your Choice
    Firefox is the most customizable browser on the planet. Customize your
toolbars to add additional buttons, install new Extensions that add new
features, add new Themes to browse with style, and use the adaptive search
system to allow you to search an infinite number of engines. Firefox is as big
or small as you want."

I simply do not agree, since it's not possible to simply change the size of the
search bar in a easy way (no, editing .css files is certainly not easy for 95%
of the computer users; the time that Phoenix/Firebird/Firefox was only for nerds
has hopefully gone by, isn't it?).

The standard size of the search bar is quite OK when your resolution is set to
800x600. The proportions between the address bar and the search bar are good in
this resolution. But most computer users are having a much higher resolution
nowadays.

As commment #80 describes, maybe we should file a bug report asking for the
default size to be larger.
Feel free to fix it #83, if you care so much to bitch. 
Why not have a toolbar element that is a XUL splitter element, which is to the
left of the search box by default, but can be moved/got rid of by customising
the toolbar? It would be best for this to be in firefox by default, so
non-techies can use it, and more advanced users can customise it to their own likes.
I've been experimenting with putting a splitter in the toolbar palette. It does
seem possible, adding the splitter element in with the elements like
toolbarspacer. I can't get it to work properly because any changes I make to
resource://chrome/toolkit.jar!content/global/bindings/toolbar.xml do not seem to
have any effect in the browser. At the moment, I've got it working for one
session, by putting a splitter in the palette using an overlay, as well as some
code changes in customizeToolbar.js. However, the toolbar does not remember the
splitter being there after firefox is closed, because of some code in
toolbar.xml. Also, when a splitter is in a toolbar, there are some more problems:

 - If the url bar gets resized smaller, then it will not be able to be risized
larger with a second resize. I think I read in a note in the javascript
somewhere that this sort of thing can be fixed by setting the 'collapse' value
to true, then false; I assume this is already a reported bug with flexing.
 - Also, the search bar does not actually resize. This just needs a flex value
attributing to it. At the moment, I'm just focussing on code changed in
customizeToolbar.js and toolbar.xml, so I haven't added that to my tests yet.
 - Thirdly, when a toolbarbutton with a picture on it is resized, the picture is
replaced by the whole picture which has all the toolbarbuttons' pictures on, and
this picture is shrunk to the size of the button. A fix for this could be
setting a minimum size for the buttons.

If I can get this splitter fix working well, I'll post it as an attachment here.
However, I need to get toolbar.xml recting before I can get to that stage.
Please make searchbox automatic resize or the width can be set manually. Thanks.
It seems the difficulty this is mainly due to wanting a dragable element/splitter to widen the search box. Although that would be nice there are other ways.
Searching is a big part of the browser, why not give it its own tab in the options dialog. The tab can be used to
- manage search engines
- manage options like opening search results in a new window or tab
- have an option for the size of the search bar; small, medium, large or even custom.
The tab can be accessed via options or from the select in the search box. 

If this is consieder a good idea, I will be happy to try do this although my XUL skills are lacking.
(In reply to comment #88)
> why not give it its own tab in the options dialog. 

Because it would add clutter to Tools/Options without adding enough value.

Better would be to have these options accessible only via the searchbar. I also think te search engines should be selectable via UI (like Thunderbird's newsgroup "Subscribe" UI), and not force the user to visit some (confusing) website. It would all be *right there* in "context".

+-------------+
|[G]          |
+-------------+
| Google      |
| Yahoo       |
| ...         |
|-------------|
| Options...  | <--- Click this, to get "Search Bar Options"
+-------------+

+- Search Bar Options ------------------------+
| _//Add Search Engines\\_/Settings\_________ |
||+----------------------+                   ||
||| A9             [ ] /\| [ Subscribe ]     ||
||| Acronym Finder [x] ||| [Unsubscribe]     ||
||| Google DE      [ ] ||| [  Refresh  ]     ||
||| Leo Eng<->Ger  [x] ||| [   Stop    ]     ||
||| Thesaurus      [ ] \/|                   ||
||+----------------------+ _Search Homepage_ ||
|+-------------------------------------------+|
|                          [[ OK ]]  [Cancel] |
+---------------------------------------------+

+- Search Bar Options ------------------------+
| _/Add Search Engines\_//Settings\\_________ |
||                                           ||
|| Open search reslts in:                    ||
||  (o) Currently open tab/window            || <-- Default!?
||  ( ) New tab                              ||
||  ( ) New window                           ||
||                                           ||
|| Size of Search Bar: [   ] pixels [Default]|| <-- dropdown: pixels, %, em ?
||                                           ||
|+-------------------------------------------+|
|                          [[ OK ]]  [Cancel] |
+---------------------------------------------+

What do you think?
(In reply to comment #89)
> Better would be to have these options accessible only via the searchbar. I also
> think te search engines should be selectable via UI (like Thunderbird's
> newsgroup "Subscribe" UI), and not force the user to visit some (confusing)
> website. It would all be *right there* in "context".

What you suggest is already in bug #232272. I don't think they depend on each other, but they are related.
(In reply to comment #90)
> (In reply to comment #89)
> > Better would be to have these options accessible only via the searchbar. I also
> > think te search engines should be selectable via UI (like Thunderbird's
> > newsgroup "Subscribe" UI), and not force the user to visit some (confusing)
> > website. It would all be *right there* in "context".
> 
> What you suggest is already in bug #232272. I don't think they depend on each
> other, but they are related.
> 

I like the options selection from Peter for just the search bar, the proposed options tabs look simple and easy to use, I feel the related bug #232272 solutions may be over complicated and do not incorporate the extra options for targeting and width. Sidebar could be an extra targeting option?
I think the functionality added by the Searchbar Autosizer plugin is optimal. Basically the searchbar stays small when empty, and continuously grows as you type more.
I don't think the search bar growing as you type is very user-friendly. I think most people generaly don't like programs doing things they haven't been told to do. The options dislogue would probably be a better solution that that. However, most non-tech people would not know what pixel or em means, so percent would have to be the default.
I think that the most user-friendly option (and the one non-tech people might expect more than any other method) is having a movable 'splitter', as I talked about in comment #86. It uses simple dragging like people are used to from re-sizing windows, etc. I'm sure this is possible, it just needs someone who knows about the workings of the toolbar to sort out the problems that I found (see comment #86).
One of the most important advantages of a bigger search box is having a bigger target when aiming for it with the mouse. The other big advantage is to check long queries without scrolling them - an auto-resizing search box would solve only one of these two problems.
(In reply to comment #94)
> One of the most important advantages of a bigger search box is having a bigger
> target when aiming for it with the mouse.

Though true that the mouse target is bigger with a bigger bar, I simply don't see this as a reason for having the search bar bigger when not in use. There are plenty of smaller mouse targets that we don't change to be unusually large just so their easier to click. Take the Back button, for example. Regardless, the minimum size of the search bar is configurable through the Searchbar Autosizer extension, and could be similarly configurable through some about:config property if someone really cared to change it from whatever we determine the best default to be.
The buttons' size can be changed via theming (correct me if I'm wrong), while right now the extension 1) is not available on addons.mozilla.org 2) leaves the resizing handle there even when not in customize mode, which clearly is not a good thing (I just want to resize it once in a while, not everyday).
I think it's also quite clear that we can't expect non-hacking users to use about:config or chrome, since *every* option that the user might reasonably want to modify should have a GUI access to it.
(In reply to comment #93)

> I don't think the search bar growing as you type is very user-friendly. I
> think most people generally don't like programs doing things they haven't been
> told to do. The options dialogue would probably be a better solution that
> that.  However, most non-tech people would not know what pixel or em means,
> so percent would have to be the default.

I think that using even percents directly would be user-unfriendly.  If we do
decide to use a user-settable, fixed width (as opposed to having the thing
resize itself automatically), the best solution would be to use a slider
control (i.e. http://www.functionx.com/visualc/controls/images/slider1.gif).
IMHO the slider should control the percentage; 20% (or around there) would
probably be a reasonable default for all display sizes, while a default size in
pixels would end up being too large or too small for small or large displays,
respectively.

> I think that the most user-friendly option (and the one non-tech people might
> expect more than any other method) is having a movable 'splitter', as I
> talked about in comment #86.

I agree that a splitter directly on the toolbar would be much easier and more
user-friendly than anything I said above :-)
(In reply to comment #89)
> (In reply to comment #88)
> > why not give it its own tab in the options dialog. 
> 
> Because it would add clutter to Tools/Options without adding enough value.
> 
> Better would be to have these options accessible only via the searchbar. I also
> think the search engines should be selectable via UI (like Thunderbird's
> newsgroup "Subscribe" UI), and not force the user to visit some (confusing)
> website. It would all be *right there* in "context".

keeping the "Options..." in the drop down for the searchbar is 
1) an accessibility issue. currently there is no way to drop down the menu with the keyboard, and consequently the options could only be reached with a mouse. (somebody please correct me here if i am wrong)

2) it splits up the various preferences into a back-door-y thing (/me struggles for right words). why not just have the current "<del>Add</del> Manage Engines..." lead to Advanced -> [tab] Search Bar -> [button->window] Add and Remove Search Engines

i think there should be a lesser dialogue that is still accessible from the main options center. more specifically:

==Advanced -> [tab] Search Bar==
presents the dialogue of yours, "Settings"
as well as a button, "Add and Remove Search Engines"

+-- Firefox Preferences (Advanced) ----------------+
| _/General\_/Update\_/Security\_//Search Bar\\___ |
||                                                ||
|| Open search results in:                        ||
||  (o) Currently open tab/window                 || <-- Default.
||  ( ) New tab                                   ||
||  ( ) New window                                ||
||                                                ||
|| Search Bar Size:                               ||
||  (o) Show drag-and-drop resizer                ||
||  ( ) Fixed width: [____]                       || <-- % ?? pixels? better yet, have a slider that is "life-size"
||  ( ) Expand to fill available space            || <-- this would split size w/ url bar
||                                                ||
||             [ Add and Remove Search Engines]   ||
|+------------------------------------------------+|
|                                                  |
|                            [Cancel]  [[ OK ]]    |
+--------------------------------------------------+


==Advanced -> [tab] Search Bar -> [button->window] Add and Remove Search engines==
brings us to your window, Peter. i have one suggestion for that: have a link/button leading to Mycroft for "Get more engines"
Yes you can drop down the list using the keyboard. ctrl+up/down cycles engines, alt+up/down opens the drop down, and up/down then work within that.
This seems to be overlooked most of the times as far as dumb end-users are concerned but someone who is a regular user of the browser would like to have such simple functionality added to the current system. Its a pity that a simple dragging of the border would not resize the toolbar. Why? We'd like to have this feature so that we can resize things to the appropriate size while having the most of the browser space for viewing pages.
Flags: blocking-firefox2?
Assignee: nobody → gavin.sharp
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2
Version: unspecified → 2.0 Branch
Status: NEW → ASSIGNED
Flags: blocking-firefox2? → blocking-firefox2+
Whiteboard: Workaround in comment #41 → Workaround in comment #41 [swag: 2d]
Summary: Make search bar resizable → Make search bar/box resizable
*** Bug 332761 has been marked as a duplicate of this bug. ***
QA Contact: toolbars → search
*** Bug 335447 has been marked as a duplicate of this bug. ***
Component: Toolbars → Search
Assignee: gavin.sharp → joe
Status: ASSIGNED → NEW
(In reply to comment #98)
> keeping the "Options..." in the drop down for the searchbar is 
> 1) an accessibility issue. currently there is no way to drop down the menu with
> the keyboard, and consequently the options could only be reached with a mouse.
> (somebody please correct me here if i am wrong)

That's a bug that should be fixed in it's own right. From what I remember of the Mozilla Wiki plan for the search bar, this was the intended way of accessing options relating to the search bar.

> || Open search results in:                        ||
> ||  (o) Currently open tab/window                 || <-- Default.
> ||  ( ) New tab                                   ||
> ||  ( ) New window                                ||

Where did this stuff come from? This bug is about making the search bar resizable, not adding a three-way preference for how it opens pages. Surely this is extension territory.

> || Search Bar Size:                               ||
> ||  (o) Show drag-and-drop resizer                ||
> ||  ( ) Fixed width: [____]                       ||
> ||  ( ) Expand to fill available space            ||

Ditto this stuff. This is Firefox, not SeaMonkey. While I'm not the one in charge, I really don't see this kind of UI cruft getting included. The value it adds is somewhat limited when an intelligent heuristic could make it entirely redundant.

In my opinion, the best thing to do here is to have a hidden pref for manually setting the size and have some kind of drag/drop resize function as part of the toolbar UI. If necessary, I don't see why a keyboard shortcut for resizing couldn't be added, it'd be no more obscure than the current CTRL+Down/CTRL+Up method of changing between plugins.
(In reply to comment #98)
> keeping the "Options..." in the drop down for the searchbar is 
> 1) an accessibility issue. currently there is no way to drop down the menu
> with the keyboard, and consequently the options could only be reached with a
> mouse. (somebody please correct me here if i am wrong)

You're wrong. See bug 283273. That's not really relevant to this bug, anyways.
Here's my personal position on this:  Make the search bar flexible and put it in the menu bar.  If you think it's crazy, at least check out the screenshots here:

http://www.codedread.com/images/Firefox15_MyChrome.png

I'm not a UI expert, but to me the best part is that you use up that wasted real estate between Help and the throbber without cutting into web page real estate...

If you made this change, I don't think anyone would require the search bar to be resizable...
(In reply to comment #105)
> Here's my personal position on this:  Make the search bar flexible and put it
> in the menu bar.  

Eh. Ok but let me move it where I want!  It's my toolbar!!!

> 
> If you made this change, I don't think anyone would require the search bar to
> be resizable...
> 

I and others want to be able to resize it as there are many valid reasons to resize it to something "resonable".

~B
The searchbar should be dynamically sized now, we're up against the wall, so this is going to have to slip in early for b1.
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
Can you change _searchBox into a property and rename it "resizableElement", or something like that, to make it easier to make this general in the future? It wouldn't be that hard to make this general now, would it? Just support a "control" attribute on the toolbarsplitter, which takes the ID of the element to be resized, and then from toolbarsplitter just check that the element has a boxObject or something. Or would you rather not do that now? If not, then I think this should probably just be put in search.xml.
(In reply to comment #110)
> Can you change _searchBox into a property and rename it "resizableElement", or
> something like that, to make it easier to make this general in the future? It

The intent is to just make a generic toolbar splitter element that resizes any nearby resizable elements, without having to specify the resized elements explicitly.  If that proves to be intractable, your proposal sounds like a good plan.
(In reply to comment #111)
> The intent is to just make a generic toolbar splitter element that resizes any
> nearby resizable elements

I created a toolbar splitter/resizer a while ago, but when it shrank toolbar buttons it messed up their pictures, and it would only shrink elements, not increase their sizes. But I didn't go far into the source code - just XUL and JS and things, not C++.

(In reply to comment #111)
> The intent is to just make a generic toolbar splitter element that resizes any
> nearby resizable elements

In that case, I think this should be kept as a search bar specific change, and a new bug filed on the better general solution. I don't think we should add a search bar-specific widget to toolbar.xml, even temporarily.
Attachment #221007 - Flags: review?(gavin.sharp) → review-
Flags: blocking-firefox2+ → blocking-firefox2-
FWIW, if bug 205011 is hypothetically fixed, it could help here. E.g., with this in toolbar.css:

#search-bar {
  width: -moz-pref("browser.toolbar.searchwidth", "15em");
}

users could then use their familiar about:config to set browser.toolbar.searchwidth to override the default value.
(In reply to comment #114)
> FWIW, if bug 205011 is hypothetically fixed, it could help here

I'm guessing you meant bug 206028 :)
I'd like to vote for this as a permanent improvement.

Bob Price.
(In reply to comment #41)
> #search-container, #searchbar {
>    -moz-box-flex: 220 !important;
> }


it appears that this no longer works in Firefox 2.0.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b)
> Gecko/20030429 Mozilla Firebird/0.6
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b)
> Gecko/20030429 Mozilla Firebird/0.6
> 
> I have made a new config-property to make the search-bar resizable:
> 
> // ---------------------------------------
> // search-bar resize hack
> var barWidth;
> barWidth =
> gPrefService.getComplexValue("browser.startup.searchwidth",Components.interfaces.nsIPrefLocalizedString).data;
> var searchBar = document.getElementById("search-bar");
> searchBar.setAttribute("width", barWidth);
> // ----------------------------------------
> 
> The patch should be added inside browser.js (browser.jar archive)
> 
> Tested with Phoenix 0.6
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 

(In reply to comment #117)
> (In reply to comment #41)
> > #search-container, #searchbar {
> >    -moz-box-flex: 220 !important;
> > }
> 
> 
> it appears that this no longer works in Firefox 2.0.
> 

Yesterday I modified the value of parameter "em:maxVersion" in one of the files of the installation file (.xpi) and at first sight now it works fine !

Inside the .xpi-file I changed, in the file install.rdf, the value of <em:maxVersion>1.5.0.*</em:maxVersion> in <em:maxVersion>2.0</em:maxVersion>. Then saved the change and installed the modified .xpi

And, till now, everything works fine !
(In reply to comment #118)
> Yesterday I modified the value of parameter "em:maxVersion" in one of the files
> of the installation file (.xpi) and at first sight now it works fine !
> 
> Inside the .xpi-file I changed, in the file install.rdf, the value of
> <em:maxVersion>1.5.0.*</em:maxVersion> in <em:maxVersion>2.0</em:maxVersion>.
> Then saved the change and installed the modified .xpi
> 
> And, till now, everything works fine !
> 


The Resize Search Box extension still works by hacking the maxVersion, but the other work around of adding the above code to userChrome.css no longer works in Firefox 2.0.
People interested in finding a workaround or fixing this bug might want to try this extension.

Searchbar Autosizer:
https://addons.mozilla.org/firefox/1172/

It's very intuitive (doesn't add cruft) and integrating something similar into Firefox should be considered. Or we can just copy IE6 and make all areas in the toolbar draggable with a right-click "lock toolbar" option.
In Firefox 2, the search bar fills the available space when moved to the menu bar. That has solved this issue for me.
(In reply to comment #120)
> People interested in finding a workaround or fixing this bug might want to try
> this extension.
> 
> Searchbar Autosizer:
> https://addons.mozilla.org/firefox/1172/
> 
> It's very intuitive (doesn't add cruft) and integrating something similar into
> Firefox should be considered. Or we can just copy IE6 and make all areas in the
> toolbar draggable with a right-click "lock toolbar" option.
> 

I'd rather it act more like this extension by default- https://addons.mozilla.org/firefox/349/
*** Bug 360867 has been marked as a duplicate of this bug. ***
I strongly disagree that Autosizer functionality should be ever integrated directly into Firefox as there's absolutely NO element on any OS that acts this way. This behaviour is completely unexpected, so I rather suggest using the "Resize Search Box" method, /while/ in customize mode to avoid unwanted resizing and because it makes sense. We can't drag & drop icons while in "normal" mode, so resizing shouldn't work either.
(In reply to comment #124)
> there's absolutely NO element on any OS that acts this way.

That's not an argument. Firefox shouldn't shy away from trying new concepts, like tabbed browsing awhile back. (I know, Firefox didn't introduce tabs, but that's not the point.)

It should really be discussed whether auto-resizing makes sense or not. I think it's quite intuitive, and I don't know a downside yet.
(In reply to comment #125)
> (In reply to comment #124)
> > there's absolutely NO element on any OS that acts this way.
> 
> That's not an argument. Firefox shouldn't shy away from trying new concepts,
> like tabbed browsing awhile back. (I know, Firefox didn't introduce tabs, but
> that's not the point.)

His point was that it's inconsistent. The UI is "locked" by default, so why should there only be one UI feature breaking this rule. As he said, why can't this functionality appear only in the customize screen?
(In reply to comment #126)
We're still talking about the auto-sizing thing, right?
I totally agree with what's being said.  Right click on the toolbar, select "Customize..." and then the resizer appears.  Resize the search box how you want it, exit customize mode, and the search bar locks.  This is the way users customize the rest of the toolbar (buttons and such), why should customizing the search bar (on the toolbar!) be any different.  It's absolutely unintuitive to do it any other way.

To put this in perspective, I'll bring up an odd analogy.  I used to work in a grocery store and all of the seasonings were kept together, except for the taco seasoning.  I used to get questions on this all the time because people looking for taco SEASONING automatically went to the SEASONING aisle.  Users looking to CUSTOMIZE the search bar will automatically go to the CUSTOMIZE menu.  No extensions, no editing userChrome.css or user.js.  It's all about the usability and intuitiveness here. 
As others have mentioned, now that Fx2 resizes the search bar when I put it in the menu bar, I no longer care about this bug, un-subscribing.
As others have mentioned, now that Fx2 resizes the search bar when I put it in the menu bar, I no longer care about this bug, un-subscribing.
woops
(In reply to comment #128)
> I totally agree with what's being said.  Right click on the toolbar, select
> "Customize..." and then the resizer appears. [...] Users looking to
> CUSTOMIZE the search bar will automatically go to the CUSTOMIZE menu.  No
> extensions, no editing userChrome.css or user.js.  It's all about the usability
> and intuitiveness here.

There's "no extensions, no editing userChrome.css or user.js" either if you implement auto-sizing. Plus, you don't have to customize anything (= intuitiveness) and chose between not wasting space and being able to read what you've typed (= usability).
I just downloaded the autosizer extension and I think, it's a great idea! Very intuitive and easy to use, no space waisted, no need to configure anything, there is even no need to touch the mouse! In fact, it's so simple that I'm wondering, why no one had come up with something like this before! ;-) Only the default minimum width should be a bit higher, IMHO, to prevent needless resizing. 

I'd vote for implementing it as core functionality - maybe not only in the search bar, but in all similar input lines.
(In reply to comment #66)
> Alternatively, the search bar could be given x% of the width of the location
> bar. E.g. the location bar could take up 75% of the available space and the
> search bar 25%. I think this would require a change to the way flexibility is
> described.

At some point, I think between 1.0 and 1.5, something like this was done (can't find a bug number - haven't bothered looking - but it did) and the search bar now expands and contracts when resizing the window. This is why it expands to fill empty space next to the menu bar. The change made flexibility a relative thing rather than all-or-nothing, so the flexible search bar could co-exist with the location bar. This was good enough for most people, particularly the high-monitor resolution sort.

It is really necessary to have the search bar be manually resizeable? Is the click target still too small? Do you really need to see all of the text you just typed all at once?

If this is going to become core functionality, someone's going to have to demonstrate a very significant usability improvement, overwhelmingly outweighing the cost of increasing the complexity of the UI (and code). Or make friends with Beltzner.
I think at the very least, something should done about the search history and suggestions being cut off. It's not cool to show "Sugg..." all the time and cut off search suggestions. The only way to see the full text is by selecting it and by then, you've already lost what you originally typed.

266 votes suggests this is an issue that needs to be addressed. Maybe this is something labs.mozilla.com can pick up to come up with most optimal solution? Mozilla recently hired a UI expert, right?

In any case, there are any number of possible solutions, all better than the current one. It seems silly to give up on something because it might make code complex. Firefox is supposed to be about innovation, isn't it? Unless by complexity, you mean degraded performance / increased memory usage, then yes I agree with you.
(In reply to comment #134)
> If this is going to become core functionality, someone's going to have to
> demonstrate a very significant usability improvement, overwhelmingly
> outweighing the cost of increasing the complexity of the UI (and code).

Adding a search bar resize is hardly "complex".  Heck, even a config entry or userChrome.css option would be better than what we have.  


(In reply to comment #135)
> In any case, there are any number of possible solutions, all better than the
> current one. It seems silly to give up on something because it might make code
> complex. Firefox is supposed to be about innovation, isn't it? Unless by
> complexity, you mean degraded performance / increased memory usage, then yes I
> agree with you.

Exactly... This is such a basic UI customization issue... and it's hardly going to be a performance killer.
My unsolicited opinion:  

I don't like my computer changing things on me without me telling it to do so, which I why I use the Resize Search Box extension rather than the autosizing one.  But in response to comment #124 - if I turn on a sidebar, I can resize it without entering customize mode.  I realize that isn't in toolbar area, but it can be done.  Same thing within Windows Explorer with the folder view enabled.  I cannot think of any default behaviour that autosizes fields in an OS or mainstream appplication and hence, my preference would be to adopt the functionality provided by Resize Search Box extension.
(In reply to comment #137)
> I don't like my computer changing things on me without me telling it to do so,

If you target unskilled users, "guessing" what they might want is a permanent challenge. Apart from that, waiting for the user to tell that a field's size should be dynamic seems quixotic. I know some of us are a little bit conservative, but the questions really are: Does auto-sizing work or does it not work? What are the advantages and disadvantages compared to other solutions? Especially with the average user in mind: Is it discoverable? Is it intuitive? All these questions deserve sober judgement and concrete answers instead of wishi washi like "I want to be in charge, I want to customize stuff" or "I never saw anything like it, it's bad".
(In reply to comment #138)
> but the questions really are: Does auto-sizing work or does it
> not work? What are the advantages and disadvantages compared to other
> solutions? Especially with the average user in mind: Is it discoverable? Is it
> intuitive?

The current auto-sizing implementation does not seem that practical.  It seems to only benefit those that always run their browser "maximized", I'm personally not one of them.  I run at 1280x1024 and 1400x1050 depending on the display and I keep firefox to a "normal size" as I like to see more than one window at once.  In cases like this the search bar is just too small, I don't want to have to maximize the window for the search bar to become an average size and in turn lose alot of valuable real estate.  One could argue that the width of the search bar is actually more important than the width of the location bar as most people don't need to read "http://.../blah/blah/blah?s=372892&xxx" but they may want to read their search string or the suggested strings being shown from their previous search results or Google Suggestions.

The advantage of the autosizing search bar is that it grows proportionally to the size of the location bar, however, I don't think people routinely resize their browser windows and therefore would benefit from autosizing.  I think most people use their browser window at a set size (whether they always maximize it or always keep it down to a typical pages width).  Given this I think it would make sense for the search bar to have a static width which a user could configure themselves via some control similar to the Resize Searchbar Extension (and the controls afforded to users in IE when the toolbar is not locked).
(In reply to comment #139)
> The current auto-sizing implementation does not seem that practical.
> [...]  In cases like this the search bar is just too small, I don't want to
> have to maximize the window for the search bar to become an average size [...]

Sorry, I meant auto-sizing as in:

(In reply to comment #120)
> Searchbar Autosizer:
> https://addons.mozilla.org/firefox/1172/
Resize search bar should be made default.
I'm getting a bit depressed by all this.
Just read the initial enhancement request : make the search text resizable.
This very simple request have been open for more than three years with discussions going all ways.
Had some kind of draggable divider been added between the url bar and the search text, the request would have been fullfilled.
I wouldn't of course mind any fancier design allowing draggable components but I can wait for those at a later time. File a seperate request if you'd like this to be.
This is yet another example of how a simple request starts debating going on an on. Five year later, still nothing has been done.
Unfortunately, the toolbar code wasn't designed to have draggable dividers. Although, theoretically, it should be possible to get something working like that, it wouldn't be very clean & efficient code - it would start to get Microsoft-y, with bits just added on as an afterthought.

(In reply to comment #143)
I don't understand what should be so difficult about this when there is a working extension which makes the search field resizable. see http://dragtotab.mozdev.org/resizesearchbox/
(In reply to comment #145)
> I don't understand what should be so difficult about this when there is a
> working extension which makes the search field resizable. see
> http://dragtotab.mozdev.org/resizesearchbox/
> 
This addon does not work with version 2.0
(In reply to comment #143)
> I'm getting a bit depressed by all this.
> Just read the initial enhancement request : make the search text resizable.
> This very simple request have been open for more than three years with
> discussions going all ways.
> Had some kind of draggable divider been added between the url bar and the
> search text, the request would have been fullfilled.
> I wouldn't of course mind any fancier design allowing draggable components but
> I can wait for those at a later time. File a seperate request if you'd like
> this to be.
> This is yet another example of how a simple request starts debating going on an
> on. Five year later, still nothing has been done.
> 

Short and to the point. Lets get this fixed!
> This addon does not work with version 2.0

It works for me on Windows XP and Linux, I'm using version 0.0.7 of the add-on with version 2.0.0.1 of Firefox.
Gentlmen,  

I'm presently using .. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10 ... and do not see the Sizeable Tool bar option, or a Panel w/in the Tools |Options menu to make the Search TextBox Sizable, Visible or Invisible.

Since I use a Motion Computing Tablet LS800 (display res at 600w x 800l) that horizontially I don't have a lot of realestate to see the Addresses in the address bar.  Nor do I use the Search TextBox.  Also note that this is a primary issue why I have not upgraded to IE 7.  It does NOT allow this Textbox to be invisible either.

So if this fix could be implemented it would be greatly appreciated.

Michael J. Fuhrman
ENetArch
Michael J. Fuhrman - you can remove the search box entirely by right clicking on the toolbar, selecting customize, then dragging the search box into the window that just popped up.

You just can't resize it yet, which is what this bug is about.
The original resizer add-on was excellent. However it needs updating for 2.0.0.3 and will no longer install. The existence of this extension has undoubtedly removed the urgency from this issue. But it isn't ideal to leave such basic functionality to be dealt with by extension. The small size of the search bar and an inability to change it is intensely frustrating to many people including myself. Losing it on upgrade is a jarring nasty experience.
(In reply to comment #151)
> The original resizer add-on was excellent. However it needs updating for
> 2.0.0.3 and will no longer install. The existence of this extension has
> undoubtedly removed the urgency from this issue. But it isn't ideal to leave
> such basic functionality to be dealt with by extension. The small size of the
> search bar and an inability to change it is intensely frustrating to many
> people including myself. Losing it on upgrade is a jarring nasty experience.

The current version of the resizer add-on is 0.8 and will work with 2.0.0.3 with the addition of Nightly Tester Tools. That aside, this continues to be a bug that just won't get fixed. I use the add-on to resize my search box on the right side after moving the search box to the far left of another tool bar. Without the add-on, the search box expands out to as much space as it wants, moving all of my other buttons, icons, etc. off to the right. Why not merge the add-on code into the base code and call it a day. This bug/enhancement has been floundering since May of 2003 - we're going on 4 YEARS now without resolution.
I don't know if anyone else has already said this, but I solve the problem by using 'Customize toolbar' to drag the Google bar up to the top menu bar (after 'Help'). This doesn't solve all the problems that have been raised but at least gives you two usable boxes. My real comment is about attitude. 
Firstly, Firefox is an excellent, user-friendly browser. Extensions enable you to use other people's cleverness easily to do most things you want. BUT there seems to be the old-fashioned open community despisal of non-nerds in the basic browser. About:config is there for anyone who wishes to alter it but takes a LOT of learning. While I understand the wish to avoid bloat, there seems to be a refusal to incorporate several of the really functional extensions. Do the designers really believe that anyone who can't handle about:config doesn't want to do/is inacapable of any customisation. If so why provide extensions? As examples: 'Resize Search Box', 'Combine stop/reload button toggle', 'open book' (which actually makes bookmarking work), and 'Tab Mix Plus'/'Mr. Tech'/'Menu Editor' which enable the configurability that 'Options' should permit. Also I can't imagine anybody NOT wanting 'Adblock', 'No Script' and the occasionally necessary last resort, 'IE View' (even if this is like going ot leaving your front door open). Probably also the basic 'Image Zoom' and 'Print Preview'. This would leave me happy with my personal 'essentials', such as 'Colorful Tabs', 'Dictionary Tooltip', 'Down Them All', 'Nuke Aything', 'Redirect Remover' and 'Translate page' as extensions.
(In reply to comment #153)
> I don't know if anyone else has already said this, but I solve the problem by
> using 'Customize toolbar' to drag the Google bar up to the top menu bar (after
> 'Help'). 

Yes, said in comment #129.  

I no longer care about this bug, as putting the search box in the Menu bar solves this problem.  However, I can't seem to successfully unsubscribe from this bug.
(In reply to comment #152)
> (In reply to comment #151)
> > The original resizer add-on was excellent. However it needs updating for
> > 2.0.0.3 and will no longer install.
> 
> The current version of the resizer add-on is 0.8 and will work with 2.0.0.3
> with the addition of Nightly Tester Tools.

I'm fairly sure the version here will work: http://dragtotab.mozdev.org/resizesearchbox/

I haven't had any trouble after upgrading to 2.0.0.3.
Dragging the search bar into the menu bar is not possible under Mac OS X.  (Just pointing out that that solution doesn't apply to everyone.)
So, now the Resize Search Box extension,  https://addons.mozilla.org/en-US/firefox/addon/349, is in the sandbox, meaning that regular users won't ever see it.  http://dragtotab.mozdev.org/resizesearchbox/ is an alternative source, but requires more savvy to find, and still has a maxversion well below the 2.0.0.5 release.
 
We've effectively removed access to functionality requested 4 years ago, and re-requested with multiple duplicate bugs and requests in these comments.  Its about time to add this. 

I find the various workarounds unacceptable for the average user:

* Autosizing is not the same as manual resizing.  If users want manual resizing, then let's just offer it.  Autosizing is an unexpected feature, which can be optional... but step one is allowing manual.

* Manually editing config files, even with the various pretty editor addins, is unacceptable.  

* Drag to the menu bar?  What the heck is that?  We have to ask the user to customize their menu, moving the search bar to an unexpected location 1/2 the height of the current location to get resizing?  That's insane.  Great hack, great workaround... but insane.

All the excitment of new javascript back ends, zooming pages, all that seems silly when we can't add the simple things people have been requesting for _4 years_ now.
Fixed by bug 267831?
Indeed. Bug 267831 added a splitter between location bar and search bar. It's available in the Customize Toolbar dialog. Just click Restore Default Set there. Please file new bugs about the new splitter and mark them as blocking bug 267831.
Status: NEW → RESOLVED
Closed: 21 years ago17 years ago
Resolution: --- → DUPLICATE
Does this still allow resizing the search bar if it is on a different toolbar than the "Navigation Toolbar"?

I hope so, otherwise I wouldn't consider this to be a dupelicate of bug 267831.
Yes, you can drag your search bar and the resizer to e.g. the bookmarks toolbar and resize it. It works on the menu bar as well (although not without funny bugs like moving menus to the right when dragging or being able to drag the search bar on top of the menus).
Michael Wexler writes;

I find the various workarounds unacceptable for the average user:

 * Autosizing is not the same as manual resizing. If users want manual resizing, then let's just offer it. Autosizing is an unexpected feature, which can be optional... but step one is allowing manual. 

* Manually editing config files, even with the various pretty editor addins, is unacceptable. 

* Drag to the menu bar? What the heck is that? We have to ask the user to customize their menu, moving the search bar to an unexpected location 1/2 the height of the current location to get resizing? That's insane. Great hack, great workaround... but insane. 

All the excitment of new javascript back ends, zooming pages, all that seems silly when we can't add the simple things people have been requesting for _4 years_ now.

I agree. 4 years and still no solution for the average user. This is most lame and needs to be a properly addressed!
Verified dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.