Closed
Bug 181806
Opened 22 years ago
Closed 1 month ago
Add "Go" button to toolbar
Categories
(Camino Graveyard :: Toolbars & Menus, enhancement, P5)
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:
Comment 1•22 years ago
|
||
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
Comment 4•20 years ago
|
||
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.
Comment 5•19 years ago
|
||
(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
Comment 6•19 years ago
|
||
Mike, repeating Jasper's comment, can we WONTFIX this?
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
I'll put a vote in for this feature, it is handy one to have.
Comment 9•19 years ago
|
||
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.
Comment 10•18 years ago
|
||
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
Comment 11•18 years ago
|
||
Im on it. Once i get CVS to work, it will be fixed.
Comment 12•18 years ago
|
||
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?
Comment 14•18 years ago
|
||
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).
Updated•18 years ago
|
Whiteboard: [Good First Bug]
Comment 15•18 years ago
|
||
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?
Comment 16•18 years ago
|
||
(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.
Comment 17•18 years ago
|
||
(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)
Comment 18•18 years ago
|
||
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
Comment 19•16 years ago
|
||
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
Comment 20•16 years ago
|
||
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.
Comment 22•16 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•