(In reply to comment #10)
> (In reply to comment #9)
> > The shortening of the searchbar in Mozilla/5.0 (Windows; U; Windows NT 5.1;
> > en-US; rv:1.8.1) Gecko/20060914 BonEcho/2.0 has made trying to see search
> > history autocomplete entries virtually impossible.
>
> This bug is the reason I think?
> https://bugzilla.mozilla.org/show_bug.cgi?id=348779
There's no good path here.
We can set a high min width on the search and address bars, and they'll stay "usable", but can't be made small.
We can try and preserve space in one at the expense of the other, but that just means that one gets very unusable fast, and we don't know which one the user cared about.
Or we can just let both shrink equally, and trust that if the user really doesn't like that, they'll either move flexy boxes onto separate rows, or else make their window bigger.
The old behavior was close to the second of these and the new behavior is closer to the third. That seems better to me.
(In reply to comment #10) /bugzilla. mozilla. org/show_ bug.cgi? id=348779
> (In reply to comment #9)
> > The shortening of the searchbar in Mozilla/5.0 (Windows; U; Windows NT 5.1;
> > en-US; rv:1.8.1) Gecko/20060914 BonEcho/2.0 has made trying to see search
> > history autocomplete entries virtually impossible.
>
> This bug is the reason I think?
> https:/
There's no good path here.
We can set a high min width on the search and address bars, and they'll stay "usable", but can't be made small.
We can try and preserve space in one at the expense of the other, but that just means that one gets very unusable fast, and we don't know which one the user cared about.
Or we can just let both shrink equally, and trust that if the user really doesn't like that, they'll either move flexy boxes onto separate rows, or else make their window bigger.
The old behavior was close to the second of these and the new behavior is closer to the third. That seems better to me.