244099 - Make Google/Search resizeable

Status: VERIFIED FIXED

(Camino Graveyard :: Toolbars & Menus, enhancement)

Description

[Eugenia Loli]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; (R1 1.1); .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: 

I need a way to make the Google/search input box a bit smaller.
I love that resizing feature on Safari: I have its Google input box always on 
minimum size which is enough for the few times I am using it, and by doing 
that I am saving real screen estate for the URL bar which users are using more 
in comparison.

Currently, your google/search input box is 150 pixels long, which is too much 
for my taste. Please either consider make it 90pixels long (on iBooks it is 
important to be able to have full URL view), or make it as Safari does and 
give us the option to resize that search box.

Reproducible: Always
Steps to Reproduce:

Actual Results:  
Too long input box for its own right and for the limited use it gets.

Expected Results:  
I would like it at 90 pixels instead of 150. Or, make it resizable.

Comment 1

[Jasper]

I do not agree with you that the Search input field should be made smaller. It's
so small now that many words get clipped at a certain point.

On the Mozilla Forum mnay people are actually requesting to enlarge it. I
altered the title of this bug to "make it resizabele" so all parties are content.

Mike and the guys what do you think?

Comment 2

[Mike Pinkerton (not reading bugmail)]

i do not believe that we can use a NSToolbar and do this, the OS just can't do
it. While i agree with you, we'd have to rewrite the entire toolbar from
scratch. I'll future it because it is a nice to have, but i don't see it ever
happening.

Comment 3

[Paul Borokhov (lensovet)]

Just out of curiousity, an idea....
I remember on the forums we were saying that for that to work, the Location and
Search items would have to be one toolbar item, and some people might not want that.
However, would it be possible to combine them into one, with a resize thing in
between, that would allow either part's width to = 0? For example, if you drag
the resizer all the way to the right, then the Search would be invisible. And if
you want it back, you can drag it back.
So would it be possible to combine Location + Search into one toolbar item and
have a resize widget in between them? Or is that still essentially the same as
rewriting the entire toolbar code?

Comment 4

[Jasper]

Attachment: text field slpitview showcase for chris

I attached a nib file containing two split view containing textfield to show
it's very easy to create such a thing in IB, it's 10.2 compatible by the way.

Comment 5

[Chris Lawson (gone)]

It looks to me like what we should do here is replace the location bar with an
NSSplitView that contains both the location bar and a search bar.

Anyone else have a better idea?

cl

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> It looks to me like what we should do here is replace the location bar with an
> NSSplitView that contains both the location bar and a search bar.

Forgive the ignorant question, but would that allow people to remove the search
field (or location field) independently of each other?

Comment 7

[Chris Lawson (gone)]

No. Basically, what I have in mind is something like what Safari does, except
we'd allow the user to minimise the search field all the way to nothing, so the
only thing left at the far right end of the location bar would be the resize
widget. Safari only allows the search field to be shrunk down to ~100px wide and
then refuses to go any smaller.

My general feeling is that changing it will help more people than it will annoy,
but those of you who've been triaging bugs for a while probably have a better
handle on this.

cl

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #7)
> No. Basically, what I have in mind is something like what Safari does, except
> we'd allow the user to minimise the search field all the way to nothing

Hmm, I see Safari 1.3.x actually lets the search field be removed independently
of the location field (but the location field removes the whole toolbar!?). 
That said, your solution sounds like a good compromise if the two cannot be
removed independently of each other.

Comment 9

[Chris Lawson (gone)]

(In reply to comment #8)

> Hmm, I see Safari 1.3.x actually lets the search field be removed independently
> of the location field (but the location field removes the whole toolbar!?). 

Safari 2.0 seems to permanently conjoin the two as one item. If one is present,
both must be. I wonder if it's a change in how Panther vs. Tiger handles the
NSSplitView class, or if the later versions of Safari has implemented it
differently (or both). Regardless, the behaviour of Safari 2.0 is what I'm
suggesting, albeit with a fully collapsible search field.

> That said, your solution sounds like a good compromise if the two cannot be
> removed independently of each other.

Like I said, Jasper suggested the split view. I'm far from an Interface Builder
expert, so if there's a better way to handle this, I'm all ears.

It was also suggested on Mozillazine that we take a look at how Shiira
implements this, which I'm about to do.

cl

Comment 10

[Jasper]

Safari 1/2 don't have a native toolbar so they can do what ever they want, we do
have a real toolbar so we will bump into some limitations. Shiira uses a
textfield which has a resize handle incorporated at the left side, which in my
opinion isn't very intuitive as you will only run into it by accident.

I think the idea of having a textfield splitview would be best. And I also think
it's a good idea to allow the user to minimise the search field all the way to
nothing. I'd bet 95% of our users have the search bar visible at all times,
maybe some have it on a different location on the toolbar, that's just to bad.

Comment 11

[Stuart Morgan]

(In reply to comment #10)
> Safari 1/2 don't have a native toolbar so they can do what ever they want

FYI, that's not true of 2.

Comment 12

[Jasper]

It is as far as I can tell, just open the browser.nib of safari and you will see
that all the toolbar icons and what not is in the nib file. I know it looks and
behaves like a real toolbar, but I have never heard of one where it was done in
a nib.

Comment 13

[Samuel Sidler (old account; do not CC)]

If the location bar and search bar were one "item" allowing the search bar to be
"hidden" by resizing it really small instead of actually removing it from the
toolbar, wouldn't this cause an extra "phantom tab" when tabbing from the
location bar into content? That doesn't seem user-friendly.

Comment 14

[Chris Lawson (gone)]

(In reply to comment #13)
> If the location bar and search bar were one "item" allowing the search bar to be
> "hidden" by resizing it really small instead of actually removing it from the
> toolbar, wouldn't this cause an extra "phantom tab" when tabbing from the
> location bar into content? That doesn't seem user-friendly.

Smokey mentioned that yesterday on MZ. I don't know enough about NSSplitView
(yet) to answer this one way or another, although it seems to me that the
logical way to handle it would be to skip over any fully collapsed children of
NSSplitView in the tab chain. Whether or not NSSplitView does this by default, I
have no idea, but it also sounds like it might not be *too* hard to work around
if it doesn't.

cl

Comment 15

[Chris Lawson (gone)]

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

Comment 16

[Chris Lawson (gone)]

Is there any particular reason we should be concerned with making this work on 10.2?

If not, I'm going to concentrate on fixing this with bug 330666 in mind.

cl

Comment 17

[Mike Pinkerton (not reading bugmail)]

landed trunk and branch.

Comment 18

[Chris Lawson (gone)]

Verified on trunk.

Comment 20

[Chris Lawson (gone)]

For housekeeping purposes, assigning to pink so it doesn't look like I did anything here and pink's the one who actually fixed it.