403959 - Cannot resize Location bar and Search bar if they are not adjacent to each other

Status: NEW

(Firefox :: Toolbars and Customization, defect, P5)

Description

[ronin.achilles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007111505 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007111505 Minefield/3.0b2pre

As per the implementation of https://bugzilla.mozilla.org/show_bug.cgi?id=400327 a resizer is automatically added when URL Bar and Search Bar are adjacent to each other. 

Now if a user places some toolbar buttons between the URL Bar and Search Bar, the resizer does not show anymore and hence there is no way that he can resize the Search or URL bar. 

This makes for an incomplete Use Case. 

Ideally a user should be able to resize the Search Bar and URL Bar so long as they are on the same toolbar (irrespective of whether they are adjacent to each other or not).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[ronin.achilles]

Attachment: Proposed Solution (clean and intuitive)

One possible solution, as shown in the attachment.

We can make each corner of the URL Bar and Search Bar behave as a resizer upon hover (hence clean, intuitive and easy to discover .. without the need of an extra resizer). So the user can simply hover on any end of any of these bars (if they are on the same toolbar) and resize them. Resizing one of them will have the obvious offsetting behavior on the other. So if the Search Bar is stretched longer, URL bar shortens and vice versa.

Even if the Search bar is placed at the right most end of the bar, the user could still select the right end of the search bar and stretch it in the right direction, but in this case since the searchbar is at the right-most end, the actual increase in length will happen on the left side (similar to what is done in many file managers).

Comment 2

[ronin.achilles]

Attachment: With Toolbar buttons between URL and Search Bar

The abovementioned solution will work even when there are toolbar buttons placed between URL bar and Search bar.

Comment 3

[Neil Deakin]

Actually the current solution can already work this way, if we change the check so that the two fields just have to be siblings instead of direct siblings as it is now.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

We'll want to test to make sure that no strange resize effects start happening. Not blocking, but wanted.

Comment 5

[RenegadeX]

(In reply to comment #0)
> Ideally a user should be able to resize the Search Bar and URL Bar so long as
> they are on the same toolbar (irrespective of whether they are adjacent to
> each other or not).

I would like to revise the above statement and say that "Ideally, a user should be able to resize the Search Bar and URL Bar independently of each other, no matter whether they are adjacent to each other or for that matter even positioned on the same toolbar as each other."

Currently (or even if Neil's suggestion in Comment 3 is implemented), both the Location Bar and Search Bar auto-stretch to fill whatever available space remains on the toolbar(s) on which it is located. Create a new blank toolbar and try dragging the Search Bar down onto it - you now have a Search Bar that fills the entire width of the screen! Perhaps you don't want it that wide.. try adding a Flexible Space next to it so that it can be shortened. Nope, doesn't work. Have fun adding dozens of Spaces in order to get it back down to its 'usual' proportions.

Why would anyone want a shorter bar (be it Location or Search)??
The default Navigation Toolbar layout is: 5 icons, Location Bar, and Search Bar. Imagine using a 22"+ widescreen monitor - the LB might be 13"+ wide, which means that the (now integrated) Star button, Go button, and clickable RSS icon are now all a long way away the part of the location bar where most typing/cutting/pasting will be done. Similarly, as resizing the bars is currently a 'give-take' thing, if the LB is made more narrow, the SB widens and we now have the Search Submit button(magnifying glass) many inches away from the Engine selector drop-down box.

This would not be an issue if both bars had drag-handles. I therefore like Ronin's suggestion for hover-over handles on both sides of each bar. Or perhaps we just need a truly flexible Flexible Space (one that can be resized while in 'Cusomtize' mode). However, Neil's Comment 3 suggestion will not address the problem.

Comment 9

[RenegadeX]

Attachment: Screencap of issue

As per Faaborg via a recent Mozillazine thread asking for Firefox 3.1 'polish'
suggestions (http://forums.mozillazine.org/viewtopic.php?f=23&t=938165) - I'm
adding him to the CC list, attaching a screenshot of the issue, and requesting someone with Bug permissions to add the following Whiteboard terms to this bug (less single quotes on each): '[polish-hard]', '[polish-visual]', '[polish-interactive]'

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

A polish bug can't be both visual and interactive.  In this case this feels like more of a missing feature, than a polish bug.  Perhaps I'm missing something, but why would anyone actually want blank space on their toolbar (and have either bar not fill all available space)?  The example of large monitors doesn't seem entirely valid to me, since on large monitors people rely less on maximized windows.

Comment 11

[(no longer active)]

As a workaround, Space elements can be added to the toolbar to make the location bar of search bar smaller.

Comment 14

[Sergey Vlasov]

Attachment: Example of having an element in between address and search bars

Comment 15

[Sergey Vlasov]

After 12 years the bug is still present.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 17

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.