Closed Bug 24651 Opened 25 years ago Closed 16 years ago

button to Clear the URL field

Categories

(SeaMonkey :: Location Bar, enhancement, P3)

x86
Linux
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX
mozilla1.1alpha

People

(Reporter: buono, Assigned: erik)

References

Details

Attachments

(10 files, 13 obsolete files)

11.02 KB, image/gif
Details
11.50 KB, image/gif
Details
3.65 KB, image/gif
Details
339 bytes, image/gif
Details
368 bytes, image/gif
Details
2.69 KB, patch
Details | Diff | Splinter Review
4.05 KB, patch
Details | Diff | Splinter Review
439 bytes, patch
Details | Diff | Splinter Review
946 bytes, image/gif
Details
22.05 KB, image/jpeg
Details
A good feature that I have never seen would be a button by the navigation buttons that would clear the web address field...rather than selecting and deleting which is very clumsy.
rfe/help wanted for some one that wants to fiddle with xul?
Assignee: chofmann → don
Summary: Clear the URL field → RFE: button to Clear the URL field
Hmmmmm ...
Summary: RFE: button to Clear the URL field → [RFE] button to Clear the URL field
Target Milestone: M20
Move to "Future" milestone.
Target Milestone: M20 → Future
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
leger is no longer @netscape. changing qa contact to component's default
QA Contact: leger → chofmann
I can't see this as being useful. We have many other bugs on making selecting the contents of the URL bar easier and quicker, and that would make this less `clumsy'. Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Component: Tracking → XP Apps: GUI Features
QA Contact: chofmann → sairuh
Resolution: --- → WONTFIX
verified.
Status: RESOLVED → VERIFIED
*** Bug 81867 has been marked as a duplicate of this bug. ***
Blake: You marked it invalid AND verified it. The RFE is very relevant for *NIX type systems though, where auto-copy takes place on selection. Reopening for reconsideration.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
-> UI Design
Assignee: vishy → mpt
Status: REOPENED → NEW
Component: XP Apps: GUI Features → User Interface Design
QA Contact: sairuh → zach
This is a *nix specific feature, and a very useful one. Get a copy of Konqueror and watch it work. It is very frustating to delete the url with the backspace key one key at a time, or to delete it all first, then copy the url, and then paste it. That would be a workaround, but nobody wants that :)
A clear button is unnecessary. Just middle-click a non-link/widget part of the content area (instead of middle-clicking the URL bar). I recommend rejecting this RFE since it would introduce unnecessary UI clutter.
A RFE well implemented would introduce no clutter at all. See that little pen on the left of the http? Just implement a right click function that erases the urlm or even faster yet, just erase it with a left click. How many lines would it take to do this? I think less than five, and i am being generous :)
OS: All → Linux
Target Milestone: Future → ---
Mozilla is not 4xp. For one, NC4.* will not paste to SAME window when clicking on content area. Another thing is that mozilla doesn't lock mouse-scrolling on a middle click mousedown. (NV4.* locks it.) This means that in mozilla, whenever i "slip" and scroll one line after mousedown: when mouse-button is released i wind up pasting whatever is on cliboard to the URL field, sending me off to Google instead. To avoid further dataloss i simply had to disable the content-area paste feature with user_pref("middlemouse.contentLoadURL", false); This RFE is a valid request.
I tested the IRIX and Solaris versions Netscape Communicator 4.7x. In both cases middle-clicking the content area loads the URL in the window whose content area was clicked--as in Mozilla. Middle-clicking WFM. Do I understand correctly that you are having problems with a wheel mouse? Wouldn't it make sense to address those issues directly? Also, invoking a search engine could be prevented by performing an URL-likeness test on the clipboard contents. (If you drag&drop a selection that contains spaces onto a Mozilla window on Mac OS Classic or on Mac OS X, Mozilla just ignores the drop.)
I have adressed the problem Ad Nauseatum. For insight on the pasting problem that lead up to the pref i refer to, read bug 57317 and dups. In particular see comment from Akkana 2001-01-08 10:47 I also filed an RFE bug 64577, in an attempt to make the current behaviour less annoying. But this all still doesn't make this RFE invalid. I would like it as a feature - very much.
I have an intellimouse explorer, and more than one time i have been scrolling and then accidentaly clicking on the middle mouse button (the wheel is there) and thus sending me to another website on the clipboard. It's very annoying , though i know how to disable it. You know it, i know it, but grandma doesn't, and you should be aiming for user-friendlyness Like i said, i think this would not even take 5 lines of code, and would be easy to test in one of the everyday night builds
Yay, the silliness of select-to-copy strikes again. I think that an `Open' button on the toolbar, as used in Navigator 3.x and earlier, would be a much less hacky solution. Of course it would be off by default, but Unix users could use it to open URLs quickly.
Maybe we dont need there to be a large clear button. Something Small and simple. Maybe a function added to the menu that pops up when you right click in the url window.
Why are you guys making a simple thing look so complicated? The button is already on the UI. The little paper and pen left of the http:// would be the button to use. Just make it erase the url when you left click on it, or right click on it and choose "delete url" off a menu. That's all it would take!
mpt, middle-click paste is not that silly if you compare it to drag&drop instead of comparing it to copy-paste. Left mouse down on the little icon (it is supposed to be a bookmark--not a pen) is reserved for starting dragging it. The context menu already includes an item called "Delete", but it requires the URL to be selected. It would be logical to make the context menu of the icon apply to the URL field even when nothing is selected, since drag actions performed on the icon apply to the entire URL. Then "Paste" could be expected to replace the URL bar contents. (Of course, the URL bar can be cleared quickly by pressing Ctrl-L and then backspace.)
Actually i did not know the ctrl-l trick. Since it's the keyboard that does the url highlighting and not the mouse, it can be erased with that trick and paste the url on the clipboard and it works So i will take it as a valid workaround Thanks
The little icon you reference is a drop source. overloading left click to _kill_ the data it is supposed to source is *BAD*. Right clicking it to clear otoh /might/ be ok.
P3.. hmm.. Consider each movement an imaginary pain. Why wrestle a keyboard unless you have to? Typing is bad enough. Mozilla is a GUI based application. When I copy/paste/scrollwheel etc. in X, my hand is on the mouse the whole time. I am Extremely lazy when it comes to computers. Lazyness is a major incentive behind many a great invention. So I use the keyboard to issue commands only when it takes me less time than doing it via the GUI. I use ctrl+X/C/V if I'm already typing something. But when using the browser i am mostly reading and clicking. So my hand is on the mouse then. If i must key a three-key combo sequence on the keyboard in order to prepare for pasting, I would have to remove my right hand from the mouse, put out the cig to avoid dropping ashes on the keyboard, remove my left hand from the coffee-cup, key in whatever, then grab cup, cig and mouse again and THEN paste, wheel, click - or whatever I was doing. It's a whole little marathon.
I know this is not an important rfe, but it's easy to do and improves user-friendlyness. If i would be familiar with mozilla's code (or c++ code altogether- i am a rookie) i would do it myself
Adding one more button to the toolbar is a much bigger 'imaginary' pain for many users, as it adds unnessary visual complexity with questionable benefits in usability. This looks like a hack to me.
Eye-movement does not burn as much calories as moving two arms. This is about ease of use. As already commented here, the interface could be incorporated into the existing interface - no extra clutter.
Does anyone object if I resummarize: "Context menu of URL bar proxy icon should apply to entire URL (not selection)"? Based on the previous comments that would be a more accurate summary.
i think the current summary is fine. The main idea is the need for a quick CLEAR function for the URL field. It could be done via context menu, but if visual clutter is an issue: why not simply let it perform in silence when right-clicking url bar down-arrow? That would also make it a "one click" thing, which is the best solution. From a context-menu it would take two clicks.
Right clicking has a predefined meaning. Overloading its meaning should not earn you many friends [in English: don't do that]. Ok, so here are some options: middle click on ... * ... url proxy to a. Clear url b. a+paste clipboard content c. b+go to new url * ... non selected urlbar a. Clear url b. a+paste clipboard content c. b+go to new url But to be honest, instead of spamming this bug, someone should open a thread in npm.unix or .xpfe or .gtk or ... asking for proposals and comments on current proposals. Keep in mind that right click and left click already have well defined semantics. mpt: you may be the default owner of UID, but as you are not an X11 user you have no business owning this bug, can you try to find someone who does? blake: my comment to mpt would apply equally well to you.
This RFE would be covered by mpt's Paste&Go menu item idea, wouldn't it? (As in, right click on the location bar, and choose "Paste & Go" which replaces the contents of the location bar with the clipboard and goes there).
I don't know what you're trying to accomplish here, but Matthew has every right in the world to own this bug. If a UI designer had to have firsthand experience with and in-depth knowledge of every interface she designed and commented on, she'd be very busy, and very slow. I've seen Matthew give some of his best UI advice on topics that he's not intimately familiar with, and it makes sense. He's in the best position to judge the idea impartially, on its merits. All he did so far in this bug was think aloud. As for your comments to me, they're nonsense. The development portion of this bug belonged in XP Apps: GUI Features, and I WONTFIX'd it (a resolution I still stand by). No one complained, and over three months later. Over a month later, someone finally did, so I passed it over to UI Design, where it now belongs. I don't own the bug, and don't know what you're talking about. There is no need to be so dramatic ("you have no business..."), to cc mozilla.org staff. Nothing here involved unusual process, it was all textbook Bugzilla procedure. You've done this in multiple bugs now; no one benefits from it, and it's just distracting.
Well... if anyone wants an ugly amateur fix: I found i didn't need the current usage of function handleURLBarRevert() - never use it - so i modified it to clear the text instead by simply adding gURLBar.value = ""; on a line below gURLBar.select(); Files: mozilla/xpfe/browser/resources/content/fastnav.js and navigator.js When urlbar has focus, hitting Esc key will then clear the current text and allow you to paste whatever with a middle button click. Seems to work fine.
Akkana: I seem to recall there is (supposed to be) a pair of emacs-/WordStar-style keybindings which you can use consecutively on Unix to clear the address field. Is that correct? Francisco: Yes, I see Konqueror's clear button in a screenshot <http://www.konqueror.org/pics/konq_navigate.png>. It looks like a pirate flag, and is not obviously related to the address field itself. I also see several other egregious UI faults in that screenshot, including renaming the `File' menu to `Location' (contravening KDE's own UI guidelines), failing to put the `Back' button in its usability-maximizing position at the left end of the toolbar, and having about 50 percent too many menus for a Web browser. So, er, I wouldn't exactly rely on Konqueror as a shining example of good UI design. R. K.: It could be the wrong time of day for me, but `the interface could be incorporated into the existing interface - no extra clutter' doesn't make any sense at all. If you have more controls in the UI, you have more clutter by definition. Yes, I know it's just `one extra button', but so is the `Add Bookmark' button which someone wanted to add to the address bar. And the `Load Images' button. And the `Copy' button. And ... and ... and ... You will have the opportunity to add (and remove) buttons once Mozilla has a customizable Toolbar, but I still see nothing here which a `Clear' button would do that an `Open' button would not do just as well or better (not to mention `Open' being 3xp). Timeless: Bite me. Hixie: `Paste & Go' dates from when I was young and innocent and thought there shouldn't be a Go button in Mozilla, and was dreaming up all sorts of creative ways to avoid it. Then I watched (and ended up having to help) many real users trying to get to a Web address without the `Go' button, and I saw the error of my ways. If no new and convincing arguments appear in the next week, this bug is probably headed on the return journey to WONTFIX land. (Provided that the Powers That Be decide I'm allowed to do that, of course.)
I searched through the existing "emacs'ish" keybindings, but didn't find any incorporated that did what i want. There's likely something available in emacs though - i don't know it well. Regarding clutter: I meant the *function* could be incorporated into existing interface. In other words be invisible. Sample implementations would be to make urlbar clear when user middle or left-click the arrow in urlbar. Or a user-pref to make ESC clear urlbar instead of revert. For my own use I've found a stupid hack that does the trick, but for the rest, a real implementation would be nice. I believe it is the need for a function rather than a button that is the real issue of this bug.
I think the "file" menu being called "location" on kde is not something to see as a bad thing. You say something about so many menus, and so i counted them. Mozilla has 10 and konqueror has 9. I hope you guys remove the QA and Debug menus inside help, or delete them once mozilla reaches 1.0 status Anyway, the konqueror thing was only to have a reference of what could be done to resolve this RFE if we would vote to make an additional button, which i think we all believe it's unnecessary clutter. So, we have made our points clear and we still are waiting for implementation of a solution. Ironically, i posted this rfe not so long ago, and i saw that it was made a long time ago (this bug) and has never been worked in. Now i learned that doing a ctrl-l and backspace would erase the url, so i am happy with this workaround. I still think the best thing to do , if any, is to implement a function in the bookmark pen (left of the url) to have a "erase url" on the menu when doing a right click on it So, can we do a vote on this and start to work? To my belief we have 3 choices 1.-New button ala konqueror (i think nobody wants this) 2.-Right click "erase url" on bookmark pen left of the url 3.-Simple keybinding on url "Esc" erases url
If you want to use the mouse only, you can do: File|Open Web Location. The textfield in the upcoming dialog is empty, so you can do the X-paste. If you just want to open the URL in the X "clipboard", you can paste it into an empty area in the browser canvas, this will load it. (In my opinion, the "proxy icon" (the bookmark icon next to the urlbar) should be the area which behaves that way, and the only one.)
I'm not getting through here. I give up. Uploaded a little something with how to modify ESC if anyone is interested. http://home.c2i.net/dark/My_Mozilla_FAQ.html
In answer to Matthew's earlier question: ^U deletes the current line; so does ^A^K (beginning of line/delete to end). Of course, you have to get focus there first if it isn't already there (accel-L). So accel-L ctrl-U is the fast way to do this on Unix.
Someone changed something in the URL field. Now i can press ESC instead of ctrl-l so i can DEL the URL field I am happy with it, besides i am now used to pasting url's in the browser window directly If it was up to me i would close this
*** Bug 88093 has been marked as a duplicate of this bug. ***
*** Bug 89364 has been marked as a duplicate of this bug. ***
This could probably be useful in windows also, though for a different reason. Have you ever watched a novice computer user type an url? I've seen lots of people click the url bar giving focus to the current url, then instead of just typing the url they use right arrow button to move to the end of the text, then hit backspace several times until they are left with http://www. I like the suggestion by Francisco Leon - to use the icon before the url to provide a dropdown, although I think it should provide several options, like: [blank] http:// http://www. ftp:// Maybe it could even be customisable in the prefs, so you could put in your most used links in the dropdown list.
Another possible solution: make clicking on the location bar select its contents on Linux, like it does on Windows. In addition or alternatively, make middle-clicking on an unfocused location bar replace the URL rather than inserting into the URL already in the location bar.
I too am frequently annoyed at having to clear the location bar through a means that loses my last selection, usually the url that I want to paste. This is one of those "damned, Mozilla would be so much more usable if it wouldn't do that" inconvenieces that is just too trivial to others to think about. I have spent a brief time in the KDE 2.2 beta, and used Konqueror. I immediately found the "Clear Location Bar" button and find myself using it time and time again. No exaggeration, I actually found it a very useful feature. The advocacy over, let's look at what's been said. mpt says that by definition, another button brings clutter, which is in these circumstances, a bad thing. Well, we need to come up with a viable solution. FWIW, I found Konqueror's UI very good, buttons were where I anticipated and I worked very quickly and easily with them. I don't claim to be representative of Fred and his friends, but that's my opinion. It's been suggested that there are a number of solutions: 1. Right-click in the urlbar, hit a new item, "Paste and Go" or similar. You have to find it, and then remember to use it. That means effort. Effort means users won't bother using it unless they believe it is reasonable for them to do it. Chuck that idea out of the window then, but tie to some string so we can retrieve if we're desperate. 2. File>Open Web Location. User has to click to get into the menu, select the right option, wait for the dialog to open, paste the url into the right text box, then hit OK or whatever. Way too long for the average user. For bookmarks, fine, but the user expects to access a web url by entering into the url bar, not via menus. Chuck that idea out of the window. 3. ctrl+l, then hit Delete or Backspace. Brilliant! Excellent. But hang on, only 1% of users who bothered to find out will ever know it exists. Oh well. Out of the window with that. What are we left with? Oh, a button. Where should we put it? Oh, this bookmarks drag-n-drop thingy is in the way, hrm, does anyone actually use that thing? I certainly don't, but I'm sure Netscape will pull a few hundred users out of a hat who they claim do use it... So, we're left with modifying what we have really cleverly then. Jesse: your last suggestion about making the selection of the text in the url bar *not* overwrite the clipboard contents is fine, and does work on Windows, but unfortunately 99% of people on Unix will select the contents of the url bar to get that url into the clipboard. Nice try though. Unfortunately, I don't have an answer here, either. I do have a couple of suggestions, though, both of which fall into various traps. I'm sure you can guess what they are respectively: 1. New menu: File>Clear URL 2. In the URL Bar's drop-down history list, have a "<blank entry>" item right at the top. Have that entry there whether history is switched on in preferences or not. Click it, and be ready to enter your url in the newly blanked url bar. I quite like this one... Well, they *might* work...
My suggestion wouldn't make it any harder to get the URL into the primary X selection. To focus the URL bar to start typing, click once, which would select the contents of the URL bar but not copy them. To copy to the current URL, select it with a drag motion, like you probably do now. (See bug 62495, clickSelectsAll should not trigger if you're selecting text.)
> which would select the contents of the URL bar but not copy them That would be too confising for users, IMO. (If it is consistent with other X apps at all.)
Not to mention contrary to expected behaviour. I still say we need a button, after all, the majority of Linux users tend not to know how to Copy/Paste the first few times, so it's really infuriating for Mozilla to clear the selection right when you want to paste an alternative selection.
The patch I've attached is against the nightly build of 29 oct 2001. It adds a 'Clear' button left of the location bar. By default the button is turned off but it can be switched on in preferences. It currently is only localised for en-US and only works for the modern theme. IMHO the button should be a small icon instead of the word 'Clear', but since I'm no graphics artist and this is a proof-of-concept I settled for the text.
Attached image Little screenshot of the Clear-button. (obsolete) —
Nice button, it adapts really good to the skin, bad thing is that it is too big and i bet i will be rejected (i would) Go to http://www.konqueror.org/pics/konq_about.png and look at how konqueror does it. Really small, no clutter. An X is really intuitive, and the caption above the button makes it work for beginners. You are on the right track and i know you can do this Erik
Yes, it does need to get smaller. I just need to dig deeper into XUL to achieve that, because I think I have to define a whole new button-class. Currently this is too much work for me, but someone with more xul experience than me could implement it in a matter of minutes, I think. Besides, I wouldn't know what icon to use. Really: what icon would be small (about the size of the bookmark-icon in the locationbar) and yet be meaningfull? I don't know, but maybe that's because I know next to nothing about UI design. So: any takers on this one? First we need an icon and next we need a smaller button to place it in.
if you can come up with an icon, try applying to these buttons (act, hov, normal). then place the button inside of the url "groove" which surrounds the url box.
Erik, any progress on this bug?
over here at: http://www.geocities.com/pratiksolanki/ see: // The following pref will disable selecting the entire URL when you // click in the URL bar. The default is true. (double clicking on the // URL will still select the entire URL for you). user_pref("browser.urlbar.clickSelectsAll", false); it should be helpful for some people here.
Progress: I tried porting my code to moz 0.9.6, but it segfaults on it. When I've got time I'll look into it again. I haven't been able to design nice looking buttons. I'm just no graphics artist. Someone else will have to do that. I'll try to make a patch to moz 0.9.6 or some recent nightly build and I'll attach it to this bug, whether or not it's in a working state yet.
Let's just keep it simple :) Really, a simple X will do. Although it'd have to be a graphic otherwise it'd look out of place. Attaching an example. You might be able to use it, or not. I doubt it, but not sure if there are any legal issues. I'll send a mail to the sylpheed developer's list to findout if this is permitted if you decide to use it.
Attached image clear button (obsolete) —
Attached patch Patch against build 2001120308 (obsolete) — Splinter Review
Second version of the 'clear location bar'-patch. Unpack the buttons in attachment 60180 [details] in chrome/skin/modern/communicator
Oh, and can someone set the 'icon' keyword for this bug?
Erik, could you create a patch for Classic?
This is basically the same as yesterday's patch, but this one includes the classic skin. You can unpack the blank buttons in the classic directory but they'll look horrible. skin/classic/navigator/navigator.css was missing from chromelist.txt, so I brute-forced it into patchmaker. This means the CVS equivalent of this file is missing from the patch. marlon: could you attach some blank classic buttons too?
The patch broke in recent builds (somewhere between dec 21 and dec 27). It doesn't apply cleanly (which is easily solvable) and clearing the location bar broke because in the `gURLBar.value = "";' in navigator.js is now ignored (NULL strings are ignored). Anybody know how to solve this?
btw Erik. There are now *two* X buttons in the tree. One to close the sidebar and one to close tabs. Couldn't you use one of those?
X-buttons are confusing, IMHO. They tend to close stuff, not wipe it. But technically: sure, no problem.
good point, but i would just hate to see this just sit and bitrot away just becuase we need an icon.
Me too, and I won't let that happen. I can't live without the clear button (really, I can't) so the patch will be maintained for as long as needed. However, I also don't want to submit a patch which is going to be rejected because of UI issues. I rather wait a bit longer for a nice icon. Maybe I'll try to create one myself next week. I'm free for the hollidays now. I'll also assign the bug to me.
Status: NEW → ASSIGNED
Hmmm, weird. 'Accept bug' assigned it to mpt. Retry.
Assignee: mpt → erik
Status: ASSIGNED → NEW
Erik: 'Accept bug' means that the current bug owner has accepted the bug. You currently have the required permissions to determine that for someone else :) When you reassign a bug, the bug State changes to New/Unconfirmed. As you clearly want this bug, accepting the bug for you.
Status: NEW → ASSIGNED
*** Bug 117147 has been marked as a duplicate of this bug. ***
Depends on: 117184
Attached patch Patch ported to 2002010208 (obsolete) — Splinter Review
The patch ported to the lastest nightly. This doesn't actually clear the location bar, but places a space (" ") in it, because of the recent location bar API change. Hopefully I'll find time to work on the graphics tomorrow.
Attachment #55715 - Attachment is obsolete: true
Attachment #55743 - Attachment is obsolete: true
Attachment #60197 - Attachment is obsolete: true
Attachment #60311 - Attachment is obsolete: true
Attached patch Patch against 2002010908 (obsolete) — Splinter Review
And there it is. This patch uses the close buttons from the standard tree. IMO they look really nice, and not confusing to the user as I was afraight of. This patch is ready for review.
Attachment #55831 - Attachment is obsolete: true
Attachment #60180 - Attachment is obsolete: true
Attachment #63367 - Attachment is obsolete: true
don't forget poor mac classic...
you should probably set some defaults too. IMHO it should default to "on" on unix-platforms and "off" on the rest. Great work Erik!
Anybody willing to help me on the Mac classic skin? I haven't got a Mac and I'm utterly clueless on how to make a patch without it. Removed 'icon' keyword.
Keywords: icon
Attached patch Default preferences (obsolete) — Splinter Review
Patch to defaults/pref/all.js and defaults/pref/unix.js. Clear button is default on on Unix, off on other platforms.
i don't agree with adding this button. the claims that it improves usability are not substantiated (other than, "Konquerer has it" which is not evidence of usability). A button's availability does not equate so simply to usability; rather, in most cases it becomes a hinderance. Currently, clearing the URL field, which is the desired task, is accomplished by overwriting the existing field contents (full text select), after focusing the field. [Double click] inside url field provided the same full text select. Therefore, our existing behavior today provides the same result as adding a "clear" button would. Thus, adding any clear-like mechanism (button) would add redundancy when 1)it is not necessary for this task, and 2)contribute to toolbar clutter 3)decreasing URL field real-estate. 2) and 3) aside, i also feel that this button would contribute unnessecary weight to toolbar customization and/or prefs, because its redundant value offers practically no improvement (off or on default), in any scenario, to completing the task of clearing the URL field. Users understand: -> select(click/focus) -> overwrite.
remember that selecting the text in the url bar overwrites the clipboard, which is annoying when you are copying and pasting links in the urlbar, however middle clicking in the browser window is fine for me
Marlon: the goal of the button is not to clear the location bar, but to clear it without copying its contents to the clipboard. This is because said clipboard sometimes holds the URL you want to copy to the location bar. On Mac and Windows this isn't an issue, on these platforms the button won't be very useful, I think. However I'm addicted to it on Unix ;-) Pasting an URL using middle-click isn't known to many people I think. A clear button is simple and clear.
> middle clicking in the browser window is fine for me This "feature" has other severe usability problems (apart from discoverability), so we shouldn't rely on it. I'm not arguing for the clear button, just against that load-by-middleclick-paste.
I would say that the button takes care of more problems then just being able to go to url in the clipboard. If you just want to type an url it is IMHO pretty bad to have to give up the contents of the clipboard (or manually deleting char- by-char the current url). So what we need is a way to clear the contents of the url-bar, and i can't think of any more user-friendly way then a button. Magic mouse-buttons or special keycombinations isn't enough for stop or reload, so why should it for clearing the urlbar, which i would think is done just as often
Unless, of course, we always clear the urlbar on focus. And restore the url on unfocus (unless it has been changed). Since you far more often want to go to a compleatly different url then edit the url you're at. But IMHO the clear-button is more user-friendly
As i am somewhat unfamiliar with Linix/Unix form conventions, my next question is, does this platform traditionally offer a "clear" button on every form field to alleviate this? Mpt mentions, that there is a key command to clear fields.
Somebody more familiar with *nix will have to answer that. However the urlbar is somewhat exceptional in that that you very often change the value in it, and most of the time to a complealy new value. In most textfields you enter a value in a blank textfield, or you modify the existing value (contrary to enter a compleatly new one) To be honest i don't really understand what the fuzz is about. I would think that the clear button is used almost as often as back/forward and more often then stop/refresh, and noone is questioning their exsitance (or?)
since the auto-copy-on-select convention is quite foreign to prevelent desktop GUIs, there's not much we can establish except consistency. Consistency with the linux platform, and consistency across the other platforms we're on. This means no button, and overriden clipboards. We can't be expected to solve every *nix UI problem with our product. If Linux users currently live with overridden clipboards routinely, then why should we be different? We shouldn't sway from the convention, because that in itself is bad practice. I don't myself know the circumstances surrounding the feature, so have no ground to change it. However, i would like to know if there was a way to override auto-copy-on select function - and offer a pref to turn back on. This would establishes Mozilla as GUI user-friendly, without totally sacrificing platform conventions. The button is still a bad idea regardless of platform.
Other suggestions: - Context menu item for selections on editable textfields. (Sorry, if I said that already.) - Add special code to clear urlbar just before paste using middleclick.
> Unless, of course, we always clear the urlbar on focus. And restore the url on > unfocus Argh! Many of us frequently edit the urlbar (e.g. to go up one level), or doubleclick the url in order to paste it into some other app. > does this platform traditionally offer a "clear" button on every form field No. > Mpt mentions, that there is a key command to clear fields. ctrl-U > However, i would like to know if there was a way to override auto-copy-on select > function - and offer a pref to turn back on Yes. user_pref("clipboard.autocopy", false); turns off autocopy. pref("browser.urlbar.clickSelectsAll", true); makes a single click in the urlbar select everything (without autocopying) whereupon you can hit delete or accel-V to paste or whatever. Also, ctrl-L shifts focus to the urlbar and selects the whole thing, without autocopying. So there are already numerous ways to get this functionality, though none of them are very discoverable. (I'm neutral on the button myself, so have been trying to stay out of the debate; I expect I'll turn it off myself because I don't want to lose urlbar real estate, but if other people want it it doesn't bother me. I have no idea what percentage of unix users would be happy to see it, and unless we do usability testing we'll probably never know the answer for sure.)
> ... > So there are already numerous ways to get this functionality, though none of > them are very discoverable. I am not worried so much about discoverability. We actually want the reverse. The desired result is that *nix users realize autocopy is turned off on the URL field. This they'll discover through ordinary use, the first time they attempt use the field in the conventional desktop GUI way, copying and pasting. Users who are troubled by the behavior will likely have the notion to look for a preference to reset it. we could oblige them with a pref in the "Smart Browsing" panel, "Enable unix-style Autocopy" check box. or elsewhere. we can't clear the URL bar on focus that's far too destructive
The location bar is an input field one often copies text to. URLs from an external mail program, user documentation (which often is in plain text), IRC, etc, etc. Other input fields are used less often or are default empty (in my experience). Changing the copy/paste behaviour on Unix would be counterintuative: why would Mozilla be the only Unix app which has Windows-style copy/paste? As a matter of fact, I like Unix copy/paste behaviour in most cases. No need to touch the keyboard at all (and that's why I've also got the 'go'-button enabled). ------ Doron: AFAIK my patch doesn't touch platform-specific bits of the skin, so there wouldn't be a need to seperately patch the Mac classic skin.
marlon, select copies on Unix. That's the way it works, the "convention", be it inferiour or not. I'd consider an app that doesn't do that broken, and no pref would be able to convince me of the opposite. Note that people do copy from the urlbar on other cases, too. marlon, this bug does not have to influence other platforms. We can pref the clear button and default to on on Unix and off on other platforms.
>We can't be expected to solve every *nix UI problem with our product.This is not a UI problem. In fact, I am an ex-Windows user that is now annoyed everytime I use Windows and *cannot* copy on select.Pure and simple, the lack of a clear button keeps me from using Mozilla. I install every new build, play with it, and end up going back to Konqueror yet wishing it had all the neat features Mozilla has. Why? Because the lack of a clear button drives me crazy.As for the middle click to paste a URL, that is a nice feature. It still does not solve the problem of pasting in a URL that you then want to edit (when for example you copy a deep link but want to just go to the main page.)This is a simple request for a button that Unix users are telling you has become an essential part of the browser UI for them. They have even gone so far as to implement it themselves and keep the patch updated to the current build. The response seems to be "Windows doesn't need it, and a UI that behaves differently than Windows is by definition broken and does not deserve special functionality." That seems to me a very bad mindset for a multi-platform browser.
i am advocating we break unix convention, to maintain desktop GUI familiarity, considering the high frequency of clipboard operations and text editing this particular form field recieves (user ability to paste into the URL field would be hindered). while i don't consider the autocopy function to be particularly clever, no matter how users have come to rely on it, I realize the harm in completely killing it. which is why i think unix people would find it useful to toggle as a pref. and this pref should not appear on non *nix platforms - Mac, and Win. Principally, clipboard contents should not be so easily wrestled away. Users rely on the clipboard to carry data around, and text editing should not be allowed to disrupt that task. Frankly, i'd yield to you unix citizens on whether the pref is off or on by default; however, not to adding another toolbar button.
> i am advocating we break unix convention, to maintain desktop GUI familiarity Uh? Unix convention *is* desktop GUI familiarity on unix platforms.
Actually, I would argue that a clear button can be usefull on other platforms too. The process of selecting the content of a textfield is something that (at least on windows) is something that is non-standard. So many "mom-users" unfamiliar with this end up unselecting the contents again and delete the contents char-by-char. For these users a clear-button would be usefull. I'm not arguing that the clear-button should default to on on other platforms then unix, or that we should stop select-on-focus'ing, I'm just trying to give additional arguments for having the clear-button. I just can't see any arguments against it. That it clutters the toolbar doesn't hold, it adds no more clutter then "stop" or "refresh".
DIE. Todd Tibbetts, congratulations, your Comment #93 managed to be unreadable in both mail and browser because it was prefixed by a > and contained no line feeds. I'm going to post this w/ nc4win because if i used QNXVoyager i would probably accidentally post w/o line feeds. first of all, don't feel that we're just giving unix users a hard time. There's a patch for password protected profiles which i think is actually getting more resistance from more people than this silly bug (whether they are equally silly is probably in the eyes of the beholder). I should probably give a brief synopsis of that bug: At startup the user has to enter a password to open a profile. The password doesn't protect or obscure any of the data in the profile, it just exists to ask you for a password (akin to having no password on your computer except for your screensaver). You should be able to right click the urlbar and select delete without triggering the click to select clobbers cutbuffer. Things not mentioned. File>Open [Location] should pop up with an empty url field which people can use. That dialog could probably be modified so that instead of closing when you click open it would tell the browser to load the page and then clear it[the dialog']s location field. Aha, there it is, Comment 18. Perfectly sane. Why can't ... oh never mind.
Why thank you timeless. I intentionally left out all the linefeeds just to thwart you. :) Was not going to clutter with a re-post, but here you go. >We can't be expected to solve every *nix UI problem with our product. This is not a UI problem. In fact, I am an ex-Windows user that is now annoyed everytime I use Windows and *cannot* copy on select.Pure and simple, the lack of a clear button keeps me from using Mozilla. I install every new build, play with it, and end up going back to Konqueror yet wishing it had all the neat features Mozilla has. Why? Because the lack of a clear button drives me crazy. As for the middle click to paste a URL, that is a nice feature. It still does not solve the problem of pasting in a URL that you then want to edit (when for example you copy a deep link but want to just go to the main page.) This is a simple request for a button that Unix users are telling you has become an essential part of the browser UI for them. They have even gone so far as to implement it themselves and keep the patch updated to the current build. The response seems to be "Windows doesn't need it, and a UI that behaves differently than Windows is by definition broken and does not deserve special functionality." That seems to me a very bad mindset for a multi-platform browser.
So how does a command qualify as a button, since we _do_ have other buttons which qualified somehow? The fact that the command is used very often? That some/many/most/all other browsers have buttons for the command? That it is obvious to the user what the button does? All of the above? Something else?
Right, so where do we go from here? Some people want the button, others don't. I can easily produce a patch which makes the button default off on all platforms. The only thing a user will notice is a new pref, which isn't very intrusive, IMHO. I'll attach a screenshot of the pref-window. Does it need any reordering? I just took the empty spot at the end of the list.
mpt is currently end running around this with his spec for customizable toolbars. the result is unix users will loses support for clicking to edit followed by pasting.
Erik, i think your screenshot proposal is fine. When toolbar customization arrives, this pref item, as will others on that panel, will become part of the new design. Be sure it is off by default for all platforms, except - Unix users decide whether it needs to be on/off by default
*** Bug 121078 has been marked as a duplicate of this bug. ***
As a *nix using and win-machines administrating being, I vote for the button to be available on all platforms via preference. *Lots* of people I watch actually click several times into the URL bar until the URL is deselected and then they remove it by hitting backspace and delete lots of times. It does help telling people in about 50% of the cases, the others just go on with it. And btw, I love copying on selection, this saves lots of time. What I would like to know from the UI-people is where the button should go. Is left of the URL bar the right place? Or should it be *in* the URL bar (like the proxy and the drop down icon)?
marlon: is the toolbar customization that you talk about in comment 103 the same as the one being talked about in bug 22056, which if I've understood you right, has been pushed for now? If so, should we really wait with Eriks patch until that is done? As far as I understand you the patch does follow the plan of how to make the button configurable as well as the defaults on all platforms.
arthur - it's not necessary on other platforms, because they don't have the same desktop conventions as *nix does. jonas - yes it's been on hold unfortunately. if i get any spare time to finish i will post it. i think that there's no reason this patch to wait for toolbar customization. it should fit in the said prefs panel, for the mean time.
Cool, thanks Marlon! Erik: I'm not really the one to review, but looking at the patches it looks fine. Except the two rules in themes/classic/navigator/navigator.css that are commented out, why is that? Who is up for review?
The two rules are stale code, they shouldn't have been in the patch. Anyway, I don't think the patch still applies cleanly to the current nightlies. Porting should be easy though. Expect a new patch by monday.
Attached patch Patch against 2002022208 (obsolete) — Splinter Review
Patch ported to 2002022208, ready for review.
Attachment #64189 - Attachment is obsolete: true
The patch has some problems in build 2002022208, it seems like bug 117184 is creeping up again. Sometimes the location bar isn't cleared when the button is clicked.
+ <image id="clear-button" onclick="clearLocBar();" clearLocationBar, please. + tooltiptext="&clearButton.tooltip;" get this next line to line up with the previous line + class="button-toolbar"/> fix those and you can have r=timeless.
Erik: IMO this should be checked in even though there is a clearing problem. Lets deal with that problem in bug 117184.
In 2002022806 the patch works fine again. No bug 117184 anymore.
Attachment #71459 - Attachment is obsolete: true
I think the best way to allow Linux users to clear the URL bar is: 1. Turn on browser.urlbar.clickSelectsAll by default on all platforms. With clickSelectsAll, the first click selects the URL but does not change the X primary selection, so there's no problem of accidentally overwriting the primary selection. This provides a large target area to click (the URL bar) and doesn't require cluttery/ugly buttons. 2. Make sure there's still an easy way to copy the URL when you want to copy it. The most obvious way to do that is to make clickSelectsAll not trigger when you're selecting text (bug 62495). That way, selecting the URL with the mouse the normal way (from left to right or vice versa) will still copy to the primary selection. 3. Make sure there's still an easy way to edit the URL. #2 takes care of the case where you're replacing or removing text from the URL. Bug 62491, "double-clicking URL with clickSelectsAll should insert caret", would take care of the case where you're adding text. I think this is the best solution on Linux, and it doesn't muck with Linux conventions any more than it mucks with Windows conventions. It also provides consistency across platforms, which isn't necessary, but is nice when you want to set up your internet cafe to run Linux.
> the first click selects the URL but does not change the X primary selection On a platform where selected text should always be in PRIMARY, this is an incredibly atrocious behavior. It completely violates user expectations in any way it possibly can, by (1) selecting text when no selection was expected and (2) not having selection do what it usually does. Please see the bugs in which unix users explain at length why clickSelectsAll should _never_ be on by default on Unix.
Comment on attachment 71881 [details] [diff] [review] Updated as per comments from timeless. Please use oncommand instead of onclick (and check to make sure that still works, of course).
Boris: the <image> element only has onclick, no oncommand. So it doesn't work.
Attached patch Updated as per comments from bz (obsolete) — Splinter Review
Now using a <button> instead of an <image>.
Attachment #71881 - Attachment is obsolete: true
Comment on attachment 73049 [details] [diff] [review] Updated as per comments from bz r=bzbarsky
Attachment #73049 - Flags: review+
Target Milestone: --- → mozilla1.0
*** Bug 130358 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0, patch
Whiteboard: Needs super-review and approval of drivers
Erik, you want to mail _a_ superreviewer and _cc_ reviewers@mozilla.org. Mail addressed solely to reviewers@mozilla.org is not likely to get read. I suggest alecf@netscape.com as a good person to ask for sr on this one.
This has to be hidden on Windows. Can you attach a picture of the dialog with the button in Classic and Modern?
Boris: thanks, I'll do that. Blake: the button is hidden by default on all platforms except Unix. I'll attach screenshots.
Attached image Screenshot of modern
Attached image Screenshot of classic
That looks too much like Stop or close
for a more obvious icon; take the X used in classic and place it over classic's & modern's bookmark icon.
Of course the buttons have tooltips, so the meaning will get clear as soon as the user hovers his pointer over the button. An X through the bookmark-icon would come out very ugly, I think. It's very hard to make a meaningful icon this small (at least for me it is). If some volunteer would give it a try: go ahead. However, this X already is quite good, IMHO. Surely its meaning isn't clear on first glance, but it'll get clear soon enough.
Attached image Suggestion for modern
Here's a suggestion for putting an x over the bookmark icon in modern. I used a slightly downsized version of the x in the delete button in mailnews.
Attached image Suggestion for classic
... and the same for classic. Using the red x from modern - the delete button in classic doesn't have an x.
please tell me that this hasn't stranded on the fact that people can't agree on an icon. We were sooo close :( Oh well.. I guess I shouldn't be surprised...
The current status of the patch is basically the same as when it's got its r= : it still applies to the current nightly (with some offsets). Abount the icons: of course it's a matter of taste. I don't pretend to be a UI expert but I like the current icons. I think it's very difficult for an icon this small to have a very meaningfull picture. An X isn't that bad, IMHO, and it'll get clear within minutes after the user starts using mozilla. I'll try asking for super review again.
I don't see this in any UI specs, nor have I seen any approval from any UI person (and please don't add me to the CC of this bug, I am both against it, and will not review until I see appropriate approval given)
Alecf: The last word in this bug from marlon bishop (which, correct me if i'm wrong, i'm not well-versed in the UI-world, is a UI person) is: "jonas - yes [the UI spec has] been on hold unfortunately. if i get any spare time to finish i will post it. i think that there's no reason this patch to wait for toolbar customization. it should fit in the said prefs panel, for the mean time."
sorry, change "UI spec" to "toolbar customization spec" in my previous comment
Comment on attachment 73049 [details] [diff] [review] Updated as per comments from bz well then! my bad. sr=alecf
Attachment #73049 - Flags: superreview+
Comment on attachment 73049 [details] [diff] [review] Updated as per comments from bz a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73049 - Flags: approval+
Erik, have you asked someone with CVS access to check the patch in? Today, we probably branch.
Whiteboard: Needs super-review and approval of drivers → Needs someone to check in approved and reviewed patch
I can check this in for erik.
Whiteboard: Needs someone to check in approved and reviewed patch
Attached patch cvs diff -u version (obsolete) — Splinter Review
Patch against current cvs -- attachments 64270 and 73049 unite.
Attachment #64270 - Attachment is obsolete: true
Attachment #73049 - Attachment is obsolete: true
Comment on attachment 78180 [details] [diff] [review] cvs diff -u version carrying forth r=timeless,bzbarsky sr=alecf a=asa
Attachment #78180 - Flags: superreview+
Attachment #78180 - Flags: review+
Attachment #78180 - Flags: approval+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Uh, why isn't this off by default?
The urlbar is already too short - please don't steal more horizontal space.
*nix default on, all others default off.
>*nix default on, all others default off. seeing this on windows too, and I have not enabled it manually
This bug was controversial enough to make it default off. I assumed it was. It's enough for those who die to have it to turn it on in prefs, together with other stuff like the Print button.
On linux, I have user_pref("browser.toolbars.showbutton.clear", false); but I still see the button. Could someone please clarify how to turn this off? Incidentally, I'd also like to turn the print button off, but I have user_pref("browser.toolbars.showbutton.print", false); and I see a print button too.
Why did this go into the 1.0 trunk?
Aside from not being able to turn this off: does anyone really think that having a small "x" right next to the big "X" of the stop button (in Modern), yet having a completely different function, is going to be clear to naive users? That alone is an argument for not making it the default, since it's more likely to confuse than help the beginning user.
Erik, Christopher, this needs to be defaulted to off and the pref needs to function. If this can't be easily fixed then please back it out until it is fixed. Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
there is +// clearbutton default on +pref("browser.toolbars.showbutton.clear", true); + in unix.js turning that false should fix it?
this problem isn't restricted to the clear-urlbar-button, I get really strange behaviour with buttons that are not in my prefs.js. It seems to ignore the values in all.js and show the buttons if they were shown at last shutdown, could be XUL-cache maybe.. continuing to investirgate
i'm so glad people on navigator actually reviewed this abomination of UI design. what on earth happened here that it got r and sr?!
This bug did not receive any module owner review from a Navigator module owners or peers.
This is a result of our wacky toolbar customization. In order to make it go away, you must check it, hit ok in prefs, go back to prefs, and uncheck it. The buttons don't ever check prefs.js to see if they need to be on, they're state is simply stored in localstore.rdf. (I think.)
The pref works fine for me, both on a fresh profile and on my exsiting one. Maybe it's a result of the pref being undefined when upgrading from an older version of mozilla? If it need to be off on all platforms by default, just back out the unix.js patch. Maybe navigator.js needs a seperate patch to make sure all preferences are defined when loading? I really don't think that the button shows up on windows due to an error in this patch. It must be the sideeffect of something else.
the easy fix is to set hidden="true" on the new <toolbarbutton>, however it would be a good idea if we actually honored the value in the preferences instead. I'm trying out a patch now...
Jason's comment explains why the prefs weren't working for me. I tried turning the checkbox on, dismissing, then off again, as he suggested, and now the button is hidden. That seems like a bug -- is there one filed? Number? Or is that what Jonas' patch will fix (for all the buttons, not just this one)?
yes i'm trying to fix this for all buttons, not just this one.
I had a similar problem when customizing Beonex Communicator. Maybe the state is stored in 2 places in localstore.rdf - once for the pref checkbox and once for the actual button. That would explain, why the pref checkbox doesn't reflect reality. You can fix this by creating a new profile, doing the workaround proposed above, close Mozilla, then compare the new profile's localstore.rdf with the default one (in profile/default). Try to sort out the related changes and moved them to the default localstore.rdf.
OK, time to back this out. The pref isn't sticking after a restart of the browser. The button looks like a mini stop button. It shows up on windows by default. Please back it out, and make it work properly before it goes in again.
this patch makes us read the preferences and set the "hidden" attribute on all buttons at startup. I'm not sure if we should keep the "persist" attributes on the different buttons. They might save a cycle or two since the buttons get the right attribute-value earlier, OTOH it adds redundency since the preference-value is saved in two places
Attachment #78180 - Attachment is obsolete: true
What kind of hit are we going to take on new window times for this?
what happens (without the patch) is this: We never actually read the preference data, the only time we use the preferences is when the browser is fully started and the user changes the preference. Otherwise we rely on persist-mechanism (which stores it's values in localstore.rdf) and the initial value of "hidden" in the xul. So if a user manually changes the value in either prefs.js or localstore.rdf (by for example removing it) the checkboxes in the preferences and the buttons will get out-of-sync and you have to do the "check-uncheck-trick" to get things working again.
i don't know how this affects startup/new-window performance and i'm outside the NS firewall so i can't test :(
drivers want this backed out. caillon, please take care of it, unless someone else gets to it first :-). Apart from the bugs, the way this was slipped in doesn't feel right. mpt isn't even on the CC list any more. (He dropped off after the bug was reassigned to Erik.) Plus see shaver and hyatt's comments. It looks like all the objectors here were ultimately just ignored, except perhaps for Marlon Bishop who just dropped the issue after claiming ignorance of Unix. Please don't try to check this in again until you have OK from mpt, hyatt and shaver, at least.
hyatt has made comments similar to the one he made here in the past, although it seems to no effect. So, just to make this completely and utterly clear: DO NOT MODIFY THE NAVIGATOR UI WITHOUT CONSULTING THE NAVIGATOR TEAM. maybe having the message all-caps will help.
Procedural issues aside, I would also like to comment on the merits of this bug. Check out http://www.freedesktop.org/standards/clipboards.txt Summary: Modern Unix UIs should not --- and will not (Qt3, GTK+) --- take much account of the PRIMARY selection. They should rely on the CLIPBOARD selection and treat it as Windows and the Mac do. Thus there is no need for us to make the Unix UI different to the Windows or Mac UI. [The problems people encounter trying to use select-to-copy/middle-mouse-paste that gave rise to this bug are *exactly* why we, along with the rest of the X desktop world, should run away screaming from that paradigm.] Arguments about novice users not discovering any of the shortcuts or workarounds to this bug seem silly to me; the chance of a novice user knowing about middle-mouse-button-paste, or understanding how it works with PRIMARY and CLIPBOARD, is close to zero. Novice users will never need this clear button. Advanced users can deal. A clear button that is disabled by default on ALL platforms could be an acceptable compromise for any disgruntled advanced users out there.
OK, let's stop beating this dead horse and become a little more productive. My advice: push this bug beyond Mozilla 1.0 until some kind of concensus is reached on what to do here, and - if this bug is decided to be fixed - there's a well-tested patch without issues.
who on the navigator team, isn't an ok from marlon enough? If naviagtor UI requires special steps for patches then that should be noted and formalized on http://www.mozilla.org/hacking/reviewers.html of course it's very bad that a patch was checked in that doesn't work, however it's not the first time it has happened and we've certainly not been so eager to back out in all previous cases.
This feature is broken: Go to Preferences and disable this icon. Then switch theme and restart. The icon will be back. Back this out.
Jonas, this patch did not get technical review from a navigator module owner or peer. Both the r and sr came from outside the Navigator module owners and peers. One of those two needed to be an r/sr, especially since the UI was affected by the change. Those people include: jag, me, hewitt, blake, ben, etc. They do not include timeless or alecf or marlon. In this case the super-reviewer really should not have given an sr on top of a timeless r, since he should have noticed this patch had not been seen by any Navigator peers or module owners.
ok, point taken. Unfortuantly module-owners or peers arn't available anywhere on mozilla.org (appart from the list you just wrote ;-) ). However this problem isn't specific to the navigator module. Anyways, i've ran Txul on attachment 78236 [details] [diff] [review] and got a perf-regression, but i need to do more testing to bulletproof the numbers. In the meanwhile I think we should set hidden="true" persist="hidden" on the <toolbarbutton> and back out unix.ps change. That way the new button will at least behave as good as the rest of the buttons. Unless the navigator team want to back out the button entierly of course. However I don't really understand Roberts comment: > Arguments about novice users not discovering any of the shortcuts or > workarounds to this bug seem silly to me; the chance of a novice user > knowing about middle-mouse-button-paste, or understanding how it works with > PRIMARY and CLIPBOARD, is close to zero. Novice users will never need this > clear button. I agree with this all the way up to the last sentence. Since users won't discover workarounds using middle-mouse-button-paste or the primary/clipboard they *will* need this button. Or have to manually clear the urlbar char-by- char. No? Advanced users can deal.
just to clarify something, i originally made the recommendation to disable the autocopy function by default - that was IMO the best solution. i finally compromised on an idea, but never did i 'OK' an actual button, nor its actual position on the toolbar - only what the pref panel might be. my comment on toolbar customization was not some sort of greenlight to check in anything someone could come up with, i am sorry if that's how it was construed. the intent of my last comment was implying a compromise on a solution, however, outside of that pref i did not agree further on what that was going to be. Frankly this bug was way off my radar after my comment 103, and hadn't given it further consideration since about 500 other features going on. nevertheless I am the guilty one, I apologize to Alec and Jonas since my comments were carelessly ambiguous and misleading. and, for not being able to stay current on my bug mail to catch it.
> Unless the navigator team want to back out the button entierly of course. Jonas, by "drivers want this backed out", I meant "drivers INSIST this be backed out, ASAP." Sorry if that wasn't clear.
> I agree with this all the way up to the last sentence. Since users won't > discover workarounds using middle-mouse-button-paste or the primary/clipboard > they *will* need this button. Or have to manually clear the urlbar char-by- > char. No? You misunderstood. Novice users WILL NOT USE middle-mouse-button-paste for anything. Windows and the Mac don't have it, and it's not discoverable. If you are using middle-mouse-button-paste, you are not a novice user, you are an advanced user.
> Jonas, by "drivers want this backed out", I meant "drivers INSIST this be > backed out, ASAP." Sorry if that wasn't clear. I thought that you might have changed your mind since there now are a fix for it not working properly. > > I agree with this all the way up to the last sentence. Since users won't > > discover workarounds using middle-mouse-button-paste or the > > primary/clipboard they *will* need this button. Or have to manually clear > > the urlbar char-by-char. No? > > You misunderstood. Novice users WILL NOT USE middle-mouse-button-paste for > anything. Windows and the Mac don't have it, and it's not discoverable. If you > are using middle-mouse-button-paste, you are not a novice user, you are an > advanced user. Exactly, and since they won't use middle-mouse-button-paste they need some way to clear the urlbar, i.e. the discussed button. I think i'm still missunderstanding you somewhere :)
The patch for this has been backed out on the trunk.
I don't know if it has something to do with this, but bringing the patches in had a really neat effect for me, I was able again to "Install Themes" with out Segfaulting and Deleting entries in the Adressbook, using both the Button and the "Del" key on my keyboard. Now the Patch is backed out, I remarked it by not seeing the handy button, I tried to "install theme" and Mozilla is segfaulting again, Deleting of Entries in the Adressbook do also not work anymore. Is it possible that this patch could have solve a problem it was not supposed to ? At least the "Delete" Function in the Adressbook was a JavaScript Error and I saw that this patch affected all.js. But maybe it is also the change of my build options, who knows. (From Static -> dynamic)
Thanks Christopher. Jonas: > Exactly, and since they won't use middle-mouse-button-paste they need some way > to clear the urlbar, i.e. the discussed button. They'll select text in some other window, Copy, select the text in the Mozilla URL bar (they'll quickly find that double-click almost always works), Paste (replacing the selected text) and hit return. Just the way it would work on any other platform.
I would like to see this button be turned on by default on unix: right now the only way to delete text from the toolbar without having mozilla mess with the clipboard is to delete its content char-by-char. btw - I _do_ want autocopy-to-clipboard to be turned on for unix - it's part of the unix UI and it's (imho) quite nice this way. Another option for clearing the URL-location entry would be to make the delete option in the content menu to clear the menu, or add a new "clear" option. These solutions are, imho, less preferable than a button. Maybe the image for the button should be changed to something different. As mentioned in comment #151, two X-buttons next to each other might be confusing to some.
I saw this button in yesterday's build and my initial reaction was, thank god about time. As it's a pain to click on the url, hit the end button and backspace char by char so I don't stomp on what's in my clipboard. Changing the way the clipboard works in linux I don't think is a good idea, as it will be confusing for many unix users, myself included. I immediately figured out that the X was to clear the url bar, one curious click solves that problem. But I'm a fearless linux geek, not your average user. The hover-over help should solve what it does for the curious, but afraid to click user. The [x] did seem kinda of odd to see up there. My initial thought maybe a [c] for clear, but it's still rather non-intuitive, but maybe better than the [x]. After all, I'd never know wtf the curved arrow does if I had never seen a web brower before. Along the same lines, I've never seen a box to clear the url on web browser before, so of course it won't be initially intuitive, but that doesn't mean it's not needed. This should definitely be on by default only on unix builds, and off by default for everything else. Great work, this is definitely something I'd like to see ironed out and in 1.0.
>Along the same lines, I've never seen a box to clear the url on >web browser before, Konqueror has one; incidentally, it also is an x button to the left of the URL bar :)
> right now the only way to delete text from the toolbar without having mozilla > mess with the clipboard is to delete its content char-by-char. This is not true for two reasons: 1) The clipboard that really matters, also known as the CLIPBOARD selection (please read http://www.freedesktop.org/standards/clipboards.txt), is not overwritten when you select text in the URL bar. [This clipboard works just like the Mac and Windows. This is the clipboard that most people understand and use.] 2) The clipboard you are using, also known as the PRIMARY selection, is really for expert users only, and expert users can work around your problem in the following ways: -- click in the URL bar, press Ctrl-U to clear the text, and then middle click to paste your URL from PRIMARY -- middle click in the content area to load your URL from PRIMARY > btw - I _do_ want autocopy-to-clipboard to be turned on for unix - it's part > of the unix UI and it's (imho) quite nice this way. Autocopy to PRIMARY is turned on and will stay turned on. But please read the freestandards.org document to see why PRIMARY is not the standard clipboard and why we should not be mangling our UI to make life better for PRIMARY users. > Changing the way the clipboard works in linux I don't think is a good idea, > as it will be confusing for many unix users, myself included. We're not changing the way any clipboard stuff works. The main confusion here is that X has multiple clipboards and most users don't know that, or don't understand how they work, which is why we need to focus on the CLIPBOARD selection as described in the freestandards.org document and leave the PRIMARY selection and its Unix-only select-to-copy mechanism to expert users only.
Robert: you make it sound like you need to be some Unix-god to understand PRIMARY. Maybe I only deal with these Unix-gods because everybody I know of uses the primary selection and not clipboard. Also: how do you copy to CLIPBOARD from an xterm? Most of the time I use the clear button it's because I'm copying an URL from IRC, a README file, etc to mozilla. The URL is always in PRIMARY. And while I do know I can paste into the content area, I tend to forget it. I don't like clearing using ctrl-U, because I'm lazy. Using the mouse, which I'm holding anyway is far easier. Is this patch acceptable when the button is turned off by default on all platforms?
> Maybe I only deal with these Unix-gods because everybody I know of uses > the primary selection and not clipboard. It's true that xterm and some other apps just don't support CLIPBOARD. That's a problem with those apps, and it's partly why a lot of Unix users got used to relying on PRIMARY and ignore CLIPBOARD. Do the people you know ever wonder why selecting text in an xterm and then choosing Paste from the Mozilla Edit menu doesn't work? Most likely they just don't ever use the Edit menu in any application unless they're pasting from within the same application. That's what I've learned to do. It sucks. X has to get out of this mess and standardizing on the CLIPBOARD selection is the only way. There are tools that can automatically copy selections from PRIMARY to CLIPBOARD which help. > Is this patch acceptable when the button is turned off by default on all > platforms? I certainly wouldn't object.
I just read about this feature on MozillaZine. And then I read that it was already backed out. I begging that it be put back in for 1.0 because I think I would love the ability to have this button. Highlighting urls in the url bar on MacOS X is kinda finiky (some times I have to click about 7 times to get it to finally highlight all the text in the url bar just so I can delete it) so if I could just click this one button the wipe the url bar I would love it!!!!!
Jonas, do you intend to have your patch (attachment 78236 [details] [diff] [review]) included in CVS? If so, do you aim for moz1.0 or moz1.1?
unfortuantly it seems to cost too many cycles when opening new windows so we have to find some other way to solve that particular problem. So that should be taken to a separate bug For now I think you should just set hidden="true" and persist="hidden" on the new <toolbarbutton> to at least get the new button on par with the rest of the buttons. However this means that we can't have different defaults on different platforms, but this seems to be what most people want anyway :-)
Attachment #78236 - Flags: needs-work+
small notes, there are two approaches to hidden, one is to put it in localstore.rdf (this is where the others are), the other would be to have hidden="&hideFooButton;" assuming you discover that dtd overhead for entities is an acceptable cost (this allows you to do per os defaults).
Paul: that's a bug that can be fixed without screwing up the UI. Bug 97822, "Click on URL bar selects only first half of URL (if mouse moves *at all* during click)."
>and leave the PRIMARY selection and its Unix-only select-to-copy mechanism to >expert users only. Fact is, this "PRIMARY" selection is just what users get used to under unix: there's a good chance a "novice", "naive" or "less-experienced" user will use it as soon as they find out. Because they like it, or because someone shows it to them: look at this... nice, huh? So PRIMARY isn't for advanced users, on the contrary... Now you say, current clipboard/selection bla sucks, and you start waving with some standards. Well, I read them, and I'm afraid I can't agree with you: (pasting from the standard, with middle mouse-button :p) b) use CLIPBOARD for the Windows-style cut/copy/paste menu items; use PRIMARY for the currently-selected text, even if it isn't explicitly copied, and for middle-mouse-click (Netscape, Mozilla, XEmacs, some GTK+ apps) The current consensus is that interpretation b) is correct. Qt 3 and GNU Emacs 21 will use interpretation b), changing the behavior of previous versions. -> use PRIMARY for the currently-selected text, even if it isn't explicitly copied <- So - user selects text -> app copies it to PRIMARY This is exactly what happens when I select text in the location bar that I want to delete. I'd rather not do that because I want to keep PRIMARY 'clean'. You state that users shouldn't use the PRIMARY for copy+paste operations. Why not? As far as I can see, that's _not_ what's in that doc: "X has a thing called "selections" which are just clipboards" So, PRIMARY is a clipboard. I can use it for copy-paste-operations. A majority of the unix users uses PRIMARY for this. So to prevent me from having to mess up PRIMARY and to save time too, give unix-users a clear button... Please?
You quote selectively. The text you quoted simply says that what we currently do is what everyone should do and that it's fine for PRIMARY to still work. Sure. The important text is here: > The correct behavior can be summarized as follows: CLIPBOARD works > just like the clipboard on Mac or Windows; it only changes on explicit > cut/copy. PRIMARY is an "easter egg" for expert users, regular users > can just ignore it; it's normally pastable only via > middle-mouse-click. Since regular users can just ignore it, and other users have workarounds that are just as good, I don't think it's right to steal screen real estate to support it.
The 'clear' button does improve mozilla's usability under unix. We have 12 votes (including me), the other major browser Konqueror has it, so Robert O'Callahan what is your point? If you dont like a clear button please dont use it or disable it. Mozilla is not in place to change how copying under Unix works at the moment. Most user I know use Primary all the time. You are talking about novice users, how many percent of the userbase are beginners? Please backup your opinion with some usability studies. So please enable the clear button by default. (BTW It is much smaller than the search or print button which I never use)
If it's not Mozilla's place to help make Linux more appealing to normal users, whose place is it?
We can't design a UI by adding every button which gets 12 votes.
What about designing a UI based on 1 vote as in bug#10096, bug#47387, and bug#72632. Or maybe 3 votes as in bug#33420 or 6 votes for bug#32087.
See comments #43, #75, #96, #105, #189 why this is nice to have on other platforms too. Lot's of novice users on win/mac delete the URL bar manually character by character (watch your daddy, grandma, non-geek-colleague). I don't mind if it's turned off by default, but I would like to be able to turn it on for the _novice_ users I set up computers. PRIMARY selection is actually the main reason why I've switched to linux, it saves so much time if you have to do lot's of copy/paste stuff. And it's the thing I've learnt to use long before I was an experienced user. PRIMARY selection rocks!
Hmm. Just to throw in my two cents.... I recently filed a bug (bug 137273 - which should probably be marked duplicate of this one) because this feature was so incredibly useful to me. The reason is simply that I did not know about the double clicking (I discovered that one this thread). The problem is that double clicking is not intuitive, since normally double clicking will select 1 (one) word, not one line, or one random group of text. So I always, selected the entire text (by dragging) and then pressed the delete, backspace or paste keys, depending on what I wanted. I vote for this bug since I believe that it makes the UI clearer and more intuitive. Note, I do use Linux and Windows builds of Mozilla, and I like the fact that the interface is the same, and personally I would enable this everywhere. By default it could be disabled, I don't mind, but I would enable it for sure!
I'll try to deliver a new patch on monday. - default off on _all_ platforms - default off after upgrading from an older version of mozilla
Status: REOPENED → ASSIGNED
I have a quit long home page URL (a bugzilla query on a local bug database). If I want to enter anything in the URLbar (like my favourite bookmark keyword "bonsai"), I always have to select the whole URL (e.g. by double-click) before I can enter anything. It would be _really_ nice if I could activate that button and simple click it for that purpose... Perhaps I'll need it a small bit less often now that you reminded me of middle-button paste page loading, I never actually used it...
Attached patch New trySplinter Review
This is the button with hidden="true" persist="hidden". On a new profile the button is hidden, the user can enable it from preferences.
Default preferences for new profiles, defaults to off on all platforms. Patch is not in CVS format.
> It's true that xterm and some other apps just don't support CLIPBOARD. xterm supports CLIPBOARD. It's just not the default for the pointer buttons. Bind some key sequences to insert-selection(CLIPBOARD) and select-end(CLIPBOARD) actions and there you go.
*** Bug 137788 has been marked as a duplicate of this bug. ***
Notice that Sun keyboards have the L-Keys, including 3 labled "Copy", "Paste", and "Cut" for accessing the CLIPBOARD. The Problem is PC keyboards don't have them. So you end up with Unix (X11) symantics with out the keys to utilize them. The windowmanagers/Desktop Environment shold have defaults for PC keyboards to gain this functionality.
Attached image just an example
Attached image screendump
My kids really like this button. I can't expect them to remember all the mozilla shortcuts. So for all mom-users, here it is :-)
Right, 1.0 is out, let's work on this patch again :-) I simply changed the target milestone and keywords; expect some real work soon.
Keywords: mozilla1.0mozilla1.1
Target Milestone: mozilla1.0 → mozilla1.1alpha
Is there a problem with your patch from comment #205? I have applied it to all releases since you posted it, and it did not give me any problems (besides not having a good icon for all themes).
Checkout the new Multizilla at mozdev.org. Next to the functionality it used to provide, it adds a clear button. Just use that icon if licensing permits it.
You can use http://diggler.mozdev.org/ until this bug is fixed.
See also bug 76010, paste onto selected text in location bar should overwrite instead of insert.
Component: User Interface Design → URL Bar
Summary: [RFE] button to Clear the URL field → button to Clear the URL field
What's the status of this? Comment #212 (from 2002-06-06) said "expect some real work soon", but than nothing happened...
I will also find this clear button very usefull for Unix. I don't understand why some of you don't want a button for this function. I have no idea about design of UIs, but I thing that if the button is useful, it should exist this button. Clearing the location bar is a task very very very frequently performed. Can you do a survey about how many people uses the little "copy source" button that it's placed at the left of the "http"? And another survey about the print button... I think that we clear the location bar more frequently than we print something.
*** Bug 186380 has been marked as a duplicate of this bug. ***
> What's the status of this? Comment #212 (from 2002-06-06) said "expect some real > work soon", but than nothing happened... I don't think it's worth the bother. The mozilla organisation doesn't seem to want it, so there's no point for me to continue working on this patch. They don't seem to care about Unix :-/ If someone wants to take over this bug: you can have it.
*** Bug 193066 has been marked as a duplicate of this bug. ***
*** Bug 199765 has been marked as a duplicate of this bug. ***
*** Bug 229679 has been marked as a duplicate of this bug. ***
Also asking for a solution, copying-and-pasting URL's with the classic Unix mouse method is a real pain in the a** with mozilla compared to Konqueror (I'm just considering Mozilla instead of Konqueror): * In Konqi, I just delete the URL field with a click on the delete button and paste the URL with the middle button. * In Moz, I first left-click into the URL field to give it focus, then perform some keyboard operations which need *both* hands (because shift or control is involved) to empty it, and then paste with the middle button.
or you press the middle mouse button over the content area...
*** Bug 324622 has been marked as a duplicate of this bug. ***
There is an Extention that adds this Feature: https://addons.mozilla.org/firefox/2342/ HTH
Another way to handle this problem is to add the 'new tab' button to the toolbar next to the URL field. Then just click 'new tab' and middle-click in the URL field to paste. But I agree an optional clear URL button is useful, and no more intrusive than the other optional buttons.
Product: Core → SeaMonkey
QA Contact: zach → location-bar
I'm closing this bug because the feature can now be easily implemented using an extension. If anybody else would like to take it, please reopen it and assign it to yourself.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago16 years ago
Resolution: --- → WONTFIX
(In reply to Erik Hensema from comment #229) > I'm closing this bug because the feature can now be easily implemented using > an extension. If anybody else would like to take it, please reopen it and > assign it to yourself. Erik, I know that this is a very old bug… but which extension should be used to modify this field? I would have through that we could hook into bug/field-end_field_column, however URL isn't a "field", and so there isn't a logical place to put the code to fixup the URL entry.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: