Closed
Bug 205011
Opened 21 years ago
Closed 17 years ago
Make search bar/box resizable
Categories
(Firefox :: Search, enhancement, P2)
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.
Reporter | ||
Updated•21 years ago
|
Severity: normal → enhancement
Reporter | ||
Comment 1•21 years ago
|
||
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
Comment 3•21 years ago
|
||
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...
Comment 4•21 years ago
|
||
*** Bug 206065 has been marked as a duplicate of this bug. ***
Comment 5•21 years ago
|
||
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
Comment 7•21 years ago
|
||
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
Comment 8•20 years ago
|
||
*** Bug 239865 has been marked as a duplicate of this bug. ***
Comment 9•20 years ago
|
||
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?
Comment 10•20 years ago
|
||
*** Bug 243072 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
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
Comment 12•20 years ago
|
||
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
Comment 13•20 years ago
|
||
*** Bug 243406 has been marked as a duplicate of this bug. ***
Comment 14•20 years ago
|
||
(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?
Comment 15•20 years ago
|
||
*** Bug 248350 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
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.
Comment 17•20 years ago
|
||
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
Comment 18•20 years ago
|
||
Of course you can also enable history for the search bar by adding: enablehistory=true Regards, Jeff
Comment 19•20 years ago
|
||
*** Bug 249457 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
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?
Comment 21•20 years ago
|
||
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.
Comment 22•20 years ago
|
||
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
Comment 23•20 years ago
|
||
(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.
Comment 24•20 years ago
|
||
*** Bug 258591 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
*** Bug 262421 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: hyatt → bugs
OS: Windows XP → All
Hardware: PC → All
Comment 26•20 years ago
|
||
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).
Comment 27•20 years ago
|
||
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.
Comment 28•20 years ago
|
||
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
Comment 29•20 years ago
|
||
> 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.
Comment 30•20 years ago
|
||
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.
Updated•20 years ago
|
Whiteboard: workaround: comment 2
Comment 31•20 years ago
|
||
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 32•20 years ago
|
||
Comment 2 doesn't work on Mac OS X with Firefox 1.0PR as per bug #267831 .
Comment 33•20 years ago
|
||
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.
Comment 34•20 years ago
|
||
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?".
Comment 35•20 years ago
|
||
*** Bug 269189 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
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.
Comment 37•20 years ago
|
||
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.
Comment 38•20 years ago
|
||
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.
Comment 39•20 years ago
|
||
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.
Comment 40•20 years ago
|
||
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.
Comment 41•20 years ago
|
||
#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
Updated•20 years ago
|
Whiteboard: Workaround in comment #41
Comment 42•20 years ago
|
||
All this should be done with the help of the mouse and not with chrome files.
Comment 43•20 years ago
|
||
*** Bug 274378 has been marked as a duplicate of this bug. ***
Comment 44•20 years ago
|
||
Don't you think a resizing widget like that extension is the way to go?
Comment 45•20 years ago
|
||
(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.
Comment 46•20 years ago
|
||
(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).
Comment 47•20 years ago
|
||
(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
Comment 48•20 years ago
|
||
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.
Comment 49•20 years ago
|
||
(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.
Comment 50•20 years ago
|
||
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.
Comment 51•20 years ago
|
||
(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.
Comment 52•20 years ago
|
||
(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.
Comment 53•20 years ago
|
||
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.
Comment 54•20 years ago
|
||
(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.
Comment 55•20 years ago
|
||
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
Comment 56•20 years ago
|
||
(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.
Comment 57•20 years ago
|
||
(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.
Comment 58•20 years ago
|
||
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.
Comment 59•20 years ago
|
||
(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.
Comment 60•20 years ago
|
||
*** Bug 276645 has been marked as a duplicate of this bug. ***
Comment 61•19 years ago
|
||
Please include Resize Seach Box by default, like it is in IE. Thanks!
Comment 62•19 years ago
|
||
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!
Comment 63•19 years ago
|
||
(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).
Comment 64•19 years ago
|
||
(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....
Comment 65•19 years ago
|
||
The resizer should only be placable between two resizable elements (e.g. address bar and search bar, in any order).
Comment 66•19 years ago
|
||
(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.
Comment 67•19 years ago
|
||
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?
Comment 68•19 years ago
|
||
removing impl' detail from summary.
Summary: Make search bar resizable in Customize Toolbars mode → Make search bar resizable
Comment 69•19 years ago
|
||
(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
Comment 70•19 years ago
|
||
(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.
Comment 71•19 years ago
|
||
(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
Comment 72•19 years ago
|
||
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.
Comment 73•19 years ago
|
||
(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
Comment 74•19 years ago
|
||
> 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.
Comment 75•19 years ago
|
||
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.
Comment 76•19 years ago
|
||
*** Bug 300758 has been marked as a duplicate of this bug. ***
Comment 77•19 years ago
|
||
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?
Comment 78•19 years ago
|
||
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.
Comment 79•19 years ago
|
||
(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.
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4-
Comment 80•19 years ago
|
||
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.
Comment 81•19 years ago
|
||
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
Comment 82•19 years ago
|
||
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.
Updated•19 years ago
|
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
Comment 83•19 years ago
|
||
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.
Comment 84•19 years ago
|
||
Feel free to fix it #83, if you care so much to bitch.
Comment 85•19 years ago
|
||
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.
Comment 86•19 years ago
|
||
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.
Comment 87•19 years ago
|
||
Please make searchbox automatic resize or the width can be set manually. Thanks.
Comment 88•19 years ago
|
||
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.
Comment 89•19 years ago
|
||
(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?
Comment 90•19 years ago
|
||
(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.
Comment 91•19 years ago
|
||
(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?
Comment 92•19 years ago
|
||
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.
Comment 93•19 years ago
|
||
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).
Comment 94•19 years ago
|
||
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.
Comment 95•19 years ago
|
||
(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.
Comment 96•19 years ago
|
||
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.
Comment 97•19 years ago
|
||
(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 :-)
Comment 98•19 years ago
|
||
(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"
Comment 99•19 years ago
|
||
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.
Comment 100•18 years ago
|
||
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.
Updated•18 years ago
|
Flags: blocking-firefox2?
Updated•18 years ago
|
Assignee: nobody → gavin.sharp
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2
Version: unspecified → 2.0 Branch
Updated•18 years ago
|
Status: NEW → ASSIGNED
Updated•18 years ago
|
Flags: blocking-firefox2? → blocking-firefox2+
Updated•18 years ago
|
Whiteboard: Workaround in comment #41 → Workaround in comment #41 [swag: 2d]
Updated•18 years ago
|
Summary: Make search bar resizable → Make search bar/box resizable
Comment 101•18 years ago
|
||
*** Bug 332761 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
QA Contact: toolbars → search
Comment 102•18 years ago
|
||
*** Bug 335447 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Component: Toolbars → Search
Assignee | ||
Updated•18 years ago
|
Assignee: gavin.sharp → joe
Status: ASSIGNED → NEW
Comment 103•18 years ago
|
||
(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.
Comment 104•18 years ago
|
||
(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.
Comment 105•18 years ago
|
||
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...
Comment 106•18 years ago
|
||
(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
Assignee | ||
Comment 107•18 years ago
|
||
Assignee | ||
Comment 108•18 years ago
|
||
Attachment #220856 -
Attachment is obsolete: true
Attachment #221007 -
Flags: review?(gavin.sharp)
Comment 109•18 years ago
|
||
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
Comment 110•18 years ago
|
||
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.
Assignee | ||
Comment 111•18 years ago
|
||
(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.
Comment 112•18 years ago
|
||
(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++.
Comment 113•18 years ago
|
||
(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.
Updated•18 years ago
|
Attachment #221007 -
Flags: review?(gavin.sharp) → review-
Updated•18 years ago
|
Flags: blocking-firefox2+ → blocking-firefox2-
Comment 114•18 years ago
|
||
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.
Comment 115•18 years ago
|
||
(In reply to comment #114) > FWIW, if bug 205011 is hypothetically fixed, it could help here I'm guessing you meant bug 206028 :)
Comment 116•18 years ago
|
||
I'd like to vote for this as a permanent improvement. Bob Price.
Comment 117•18 years ago
|
||
(In reply to comment #41) > #search-container, #searchbar { > -moz-box-flex: 220 !important; > } it appears that this no longer works in Firefox 2.0.
Comment 118•18 years ago
|
||
(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 !
Comment 119•18 years ago
|
||
(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.
Comment 120•18 years ago
|
||
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.
Comment 121•18 years ago
|
||
In Firefox 2, the search bar fills the available space when moved to the menu bar. That has solved this issue for me.
Comment 122•18 years ago
|
||
(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/
Comment 123•18 years ago
|
||
*** Bug 360867 has been marked as a duplicate of this bug. ***
Comment 124•18 years ago
|
||
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.
Comment 125•18 years ago
|
||
(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.
Comment 126•18 years ago
|
||
(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?
Comment 127•18 years ago
|
||
(In reply to comment #126) We're still talking about the auto-sizing thing, right?
Comment 128•18 years ago
|
||
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.
Comment 129•18 years ago
|
||
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.
Comment 130•18 years ago
|
||
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.
Comment 131•18 years ago
|
||
woops
Comment 132•18 years ago
|
||
(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).
Comment 133•18 years ago
|
||
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.
Comment 134•18 years ago
|
||
(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.
Comment 135•18 years ago
|
||
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.
Comment 136•18 years ago
|
||
(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.
Comment 137•18 years ago
|
||
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.
Comment 138•18 years ago
|
||
(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".
Comment 139•18 years ago
|
||
(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).
Comment 140•18 years ago
|
||
(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/
Comment 141•18 years ago
|
||
Resize search bar should be made default.
Comment 143•17 years ago
|
||
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.
Comment 144•17 years ago
|
||
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)
Comment 145•17 years ago
|
||
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/
Comment 146•17 years ago
|
||
(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
Comment 147•17 years ago
|
||
(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!
Comment 148•17 years ago
|
||
> 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.
Comment 149•17 years ago
|
||
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
Comment 150•17 years ago
|
||
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.
Comment 151•17 years ago
|
||
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.
Comment 152•17 years ago
|
||
(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.
Comment 153•17 years ago
|
||
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.
Comment 154•17 years ago
|
||
(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.
Comment 155•17 years ago
|
||
(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.
Comment 157•17 years ago
|
||
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.)
Comment 158•17 years ago
|
||
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.
Comment 159•17 years ago
|
||
Fixed by bug 267831?
Comment 160•17 years ago
|
||
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 ago → 17 years ago
Resolution: --- → DUPLICATE
Comment 161•17 years ago
|
||
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.
Comment 162•17 years ago
|
||
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).
Comment 163•17 years ago
|
||
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.
Description
•