Closed Bug 181806 Opened 22 years ago Closed 1 month ago

Add "Go" button to toolbar

Categories

(Camino Graveyard :: Toolbars & Menus, enhancement, P5)

PowerPC
macOS
enhancement

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Future

People

(Reporter: mozilla, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

Mozilla has a button marked "go" that can be added to the toolbar. This button
is essentially the same as hitting "enter" in the URL bar, but it is nice to
have for cutting and pasting URLs and hitting "go" instead of taking a hand off
of the mouse to hit "Enter." I would like to see this added as an option for the
toolbar in Chimera.

Reproducible: Always

Steps to Reproduce:
As stupid as this may sound :-) , I actually found it useful as well, every once
in a while (such as, when my keyboard is broken :-/ ).

Button should be off by default though (e.g. just put it in the customize list).
Status: UNCONFIRMED → NEW
Ever confirmed: true
-->sfraser for triage
Assignee: brade → sfraser
Mike could we set this as WONTFIX?
A much-needed feature, I think that a much better option would be to add an item
to the contextual menu that comes up in the Location bar called "Paste and Go".
This would accomplish two things with one click: paste the URL from the
clipboard and immediately start loading the page. No need for special buttons,
and more useful too (no need to move the mouse or click!)
I'm also thinking that this would require less coding.
(In reply to comment #4)
> A much-needed feature, I think that a much better option would be to add an item
> to the contextual menu that comes up in the Location bar called "Paste and Go".
> This would accomplish two things with one click: paste the URL from the
> clipboard and immediately start loading the page. No need for special buttons,
> and more useful too (no need to move the mouse or click!)
> I'm also thinking that this would require less coding.

If you have a URL in the clipboard, you can drag it right into Camino. I agree
with Jasper. This should be WONTFIXed. I can see why people might want it
though, so keeping discussion opening but targeting for FUTURE.
Priority: -- → P5
Target Milestone: --- → Future
Mike, repeating Jasper's comment, can we WONTFIX this?
Is this THAT hard to do? Dragging doesn't work with every app, and how is it
supposed to work anyway? What if I have an e-mail that takes up the entire
screen - I can't drag that into Camino's window, and dragging to the dock icon
doesn't work in one of my apps already  - just checked.
I would also like to point out that as a general rule, drag-and-drop is very
handy, but must never be the only way to do something. There are times when it's
just hard to do!
It seems to me that an option like Paste-and-Go would not require a lot of
coding and would be greatly appreciated by a lot of users, especially those
switching from other Mozilla browsers (who all have Go buttons) and PCs.
I'll put a vote in for this feature, it is handy one to have.
Hmm...when I finally get around to learning Cocoa in about 2 years or so...I'd
give this a shot ;) ... until then ... please don't change it to WONTFIX.
For a lot of beginners, this is important and I can see *some* value in having it, despite my desire to WONTFIX it. Also, this would be a great first bug for someone.

Targeting for 2.0.
QA Contact: bugzilla → toolbars
Target Milestone: Future → Camino2.0
Im on it.  Once i get CVS to work, it will be fixed.
What if we have a little button in the end of the URL bar, next to the padlock? I think this might be better than some random Go toolbar button that the user can drag to some other place by mistake, and get confused.
(In reply to comment #12)
> What if we have a little button in the end of the URL bar, next to the padlock?

And then we end up with the lock, this "Go" icon, the pop-up blocked notification, and the feed notification, and maybe other notifications in the future, all in the location bar.  It's distracting and cluttered on a long location bar and downright cramped with the default toobar set at the default window size.

Moreover, I think placing other items in the location bar dilutes the "strength" of the lock in the location bar; the lock gets to be there because it is security-related--that makes it special and unique, so the user knows that when something shows up in the location bar, that something is important (secure/encrypted connection)....  Putting other notifications or objects in the bar breaks that (and it's hard enough to tell the mixed content lock from the completely encrypted lock already).

> I think this might be better than some random Go toolbar button that the user
> can drag to some other place by mistake, and get confused.

I agree with this, though...could we put it in the split view and make it hideable like the search field?
first off...why would anyone be confused by a "go" button?
second...you can't just "move" it, you'd have to hold command down, then click and drag with your mouse for it to move anywhere.
smokey, i think a split view makes sense for text fields, or lists, etc, but for a button? that would look weird. what's wrong with just having this as a button all on its own? why make this harder than it needs to be?
also to graham, are you working on a button or a context menu item? personally i find the latter much more useful for copy and paste operations (i.e. have a Paste & Go menu item that pastes the clipboard and then opens the pasted url).
Whiteboard: [Good First Bug]
How would this work with the recent location and search bar changes? Now that they are combined into one element (to allow for search bar resizing) does this mean that a 'go' button would be a constant part of that set - rather than being an option?
(In reply to comment #15)
> How would this work with the recent location and search bar changes? Now that
> they are combined into one element (to allow for search bar resizing) does this
> mean that a 'go' button would be a constant part of that set - rather than
> being an option?

I think this is something we should talk about at our next meeting. The overall discussion we had the last time we talked was WONTFIX, but it's something we should discuss.
(In reply to comment #15)
> How would this work with the recent location and search bar changes? Now that
> they are combined into one element (to allow for search bar resizing) does this
> mean that a 'go' button would be a constant part of that set - rather than
> being an option?
it really wouldn't work, but the "Paste & Go" alternative is still feasible (as an addition to the ctrl-click menu you get inside the URL bar)
At our meeting today, we decided that the best way to do this would be with "sticky" toolbar buttons, whereby the "go" button, when added to the toolbar, would be stuck to the end of the location bar, and could only be placed there. 

Other implementations -- having two location bars (one with go, one without), having a separate go button that could be placed anywhere in the toolbar, having a go button for everyone and not allowing it to be removed -- are considered less than ideal and not really in the realm of what we want to do.

This currently isn't possible with cocoa toolbars and as such, I'm futuring this bug.

In short, we won't need graphics for this bug for a long time, if at all, but it is something we want to do eventually... we just want to do it right.

(Paste and go isn't really part of this bug and is a separate issue.)
Assignee: sfraser_bugs → nobody
Whiteboard: [Good First Bug]
Target Milestone: Camino2.0 → Future
Behaviour in Firefox 3.0 is to display a Go icon (white right-pointing triangle in an orange circle) on the right end of the location bar. Current behaviour is broken however, as they remove all other right end icons during editing and fail to put them back if editing is cancelled.

This would be very doable to implement properly in Camino:
1. On begin editing, remove all right end icons and add a Go button (using similar code to that for the feed and security icons)
2. If the user clicks on the Go button, load the current text in the text field in the current tab.
3. If the user ends editing, remove the Go button and put the icons back
I'd be fine with a transient internal Go button.
I'd really rather not see us continue to overload the location bar, no matter how transient the icon (see again comment 13).  I'm also a little concerned that we might start confusing people when the feed icon and the lock start disappearing and re-appearing.
This would only be while they are tying though--and really, once they have typed another URL, everything in the location bar is arguably confusing, since it doesn't apply to what they have typed (see for example the favicon and the weird behavior of dragging it while another URL is typed).

I tend to think we should move toward the Firefox model where the whole URL bar resets to a bare state when something else is typed into it, which the go button would fit with.
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.