Last Comment Bug 24651 - button to Clear the URL field
: button to Clear the URL field
Status: RESOLVED WONTFIX
:
Product: SeaMonkey
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: x86 Linux
: P3 enhancement with 21 votes (vote)
: mozilla1.1alpha
Assigned To: Erik Hensema
:
:
Mentors:
: 81867 89364 117147 121078 130358 137788 186380 193066 199765 229679 324622 (view as bug list)
Depends on: 117184
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-21 08:41 PST by Scott Buono
Modified: 2015-12-19 21:02 PST (History)
49 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Provides a basic clear button for the location bar (3.36 KB, patch)
2001-10-30 03:06 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Little screenshot of the Clear-button. (16.74 KB, image/gif)
2001-10-30 08:39 PST, Erik Hensema
no flags Details
blank modern buttons to "have a go" with (3.47 KB, application/zip)
2001-10-30 15:38 PST, marlon bishop
no flags Details
clear button (867 bytes, image/png)
2001-12-03 10:48 PST, yatsu
no flags Details
Patch against build 2001120308 (3.53 KB, patch)
2001-12-03 12:25 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Patch against build 2001120321, includes classic (4.17 KB, patch)
2001-12-04 03:57 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Patch ported to 2002010208 (4.14 KB, patch)
2002-01-03 05:48 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Patch against 2002010908 (4.10 KB, patch)
2002-01-09 14:05 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Default preferences (804 bytes, patch)
2002-01-10 02:38 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Screenshot of preferences window (11.02 KB, image/gif)
2002-01-16 03:45 PST, Erik Hensema
no flags Details
Patch against 2002022208 (3.88 KB, patch)
2002-02-26 03:16 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Updated as per comments from timeless. (3.90 KB, patch)
2002-02-28 08:49 PST, Erik Hensema
no flags Details | Diff | Splinter Review
Updated as per comments from bz (4.02 KB, patch)
2002-03-07 13:56 PST, Erik Hensema
bzbarsky: review+
alecf: superreview+
asa: approval+
Details | Diff | Splinter Review
Screenshot of modern (11.50 KB, image/gif)
2002-03-12 14:47 PST, Erik Hensema
no flags Details
Screenshot of classic (3.65 KB, image/gif)
2002-03-12 14:48 PST, Erik Hensema
no flags Details
Suggestion for modern (339 bytes, image/gif)
2002-03-15 02:14 PST, Lasse Marøen
no flags Details
Suggestion for classic (368 bytes, image/gif)
2002-03-15 02:17 PST, Lasse Marøen
no flags Details
cvs diff -u version (7.06 KB, patch)
2002-04-08 06:47 PDT, Christopher Aillon (sabbatical, not receiving bugmail)
caillon: review+
caillon: superreview+
caillon: approval+
Details | Diff | Splinter Review
makes us honor the preferenes rather then rely on localstore.rdf (2.69 KB, patch)
2002-04-08 14:26 PDT, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details | Diff | Splinter Review
New try (4.05 KB, patch)
2002-04-15 09:53 PDT, Erik Hensema
no flags Details | Diff | Splinter Review
Default preferences, again not in CVS format (439 bytes, patch)
2002-04-15 09:56 PDT, Erik Hensema
no flags Details | Diff | Splinter Review
just an example (946 bytes, image/gif)
2002-05-14 05:08 PDT, HJ
no flags Details
screendump (22.05 KB, image/jpeg)
2002-05-14 05:38 PDT, HJ
no flags Details

Description Scott Buono 2000-01-21 08:41:40 PST
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.
Comment 1 chris hofmann 2000-02-03 03:58:58 PST
rfe/help wanted for some one that wants to fiddle with xul?
Comment 2 don 2000-02-08 15:24:37 PST
Hmmmmm ...
Comment 3 don 2000-05-25 13:58:42 PDT
Move to "Future" milestone.
Comment 4 Viswanath Ramachandran 2000-12-06 11:23:39 PST
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Comment 5 Dawn Endico 2000-12-21 14:04:51 PST
leger is no longer @netscape. changing qa contact to component's default
Comment 6 Blake Ross 2001-01-06 17:36:14 PST
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.
Comment 7 Blake Ross 2001-04-14 18:24:25 PDT
verified.
Comment 8 R.K.Aa. 2001-05-20 12:21:22 PDT
*** Bug 81867 has been marked as a duplicate of this bug. ***
Comment 9 R.K.Aa. 2001-05-20 12:22:58 PDT
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.
Comment 10 Blake Ross 2001-05-20 12:31:58 PDT
-> UI Design
Comment 11 Francisco León 2001-05-20 12:39:01 PDT
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 :)
Comment 12 Henri Sivonen (:hsivonen) 2001-05-20 16:29:12 PDT
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.
Comment 13 Francisco León 2001-05-20 17:12:41 PDT
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 :)
Comment 14 R.K.Aa. 2001-05-21 02:18:34 PDT
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.
Comment 15 Henri Sivonen (:hsivonen) 2001-05-21 03:41:48 PDT
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.)
Comment 16 R.K.Aa. 2001-05-21 03:59:58 PDT
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.
Comment 17 Francisco León 2001-05-21 06:55:26 PDT
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
Comment 18 Matthew Paul Thomas 2001-05-21 07:09:50 PDT
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.
Comment 19 Scott Buono 2001-05-21 07:12:40 PDT
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.
Comment 20 Francisco León 2001-05-21 07:23:32 PDT
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!
Comment 21 Henri Sivonen (:hsivonen) 2001-05-21 08:47:23 PDT
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.)
Comment 22 Francisco León 2001-05-21 09:49:57 PDT
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
Comment 23 timeless 2001-05-21 11:08:41 PDT
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.
Comment 24 R.K.Aa. 2001-05-23 15:49:56 PDT
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.
Comment 25 Francisco León 2001-05-23 15:59:36 PDT
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
Comment 26 german 2001-05-24 11:17:52 PDT
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.
Comment 27 R.K.Aa. 2001-05-24 11:27:58 PDT
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.
Comment 28 Henri Sivonen (:hsivonen) 2001-05-24 13:18:15 PDT
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.
Comment 29 R.K.Aa. 2001-05-24 13:52:10 PDT
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.
Comment 30 timeless 2001-05-24 18:20:06 PDT
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.
Comment 31 Hixie (not reading bugmail) 2001-05-24 19:39:15 PDT
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).
Comment 32 Blake Ross 2001-05-24 19:56:13 PDT
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.
Comment 33 R.K.Aa. 2001-05-25 01:27:57 PDT
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.
Comment 34 Matthew Paul Thomas 2001-05-26 09:30:46 PDT
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.)
Comment 35 R.K.Aa. 2001-05-26 13:08:38 PDT
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.
Comment 36 Francisco León 2001-05-26 17:23:37 PDT
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 
Comment 37 Ben Bucksch (:BenB) 2001-05-27 17:48:51 PDT
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.)
Comment 38 R.K.Aa. 2001-05-27 18:25:53 PDT
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
Comment 39 Akkana Peck 2001-06-26 15:00:08 PDT
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.
Comment 40 Francisco León 2001-06-26 15:07:13 PDT
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
Comment 41 R.K.Aa. 2001-06-27 20:27:51 PDT
*** Bug 88093 has been marked as a duplicate of this bug. ***
Comment 42 Francisco León 2001-07-05 09:31:06 PDT
*** Bug 89364 has been marked as a duplicate of this bug. ***
Comment 43 Lasse Marøen 2001-07-05 14:48:32 PDT
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.
Comment 44 Jesse Ruderman 2001-07-05 17:52:29 PDT
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.
Comment 45 James Green 2001-08-04 14:39:46 PDT
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...
Comment 46 Jesse Ruderman 2001-08-21 18:43:21 PDT
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.)
Comment 47 Ben Bucksch (:BenB) 2001-08-21 22:20:37 PDT
> 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.)
Comment 48 James Green 2001-08-22 07:10:18 PDT
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.

Comment 49 Erik Hensema 2001-10-30 03:06:42 PST
Created attachment 55715 [details] [diff] [review]
Provides a basic clear button for the location bar
Comment 50 Erik Hensema 2001-10-30 03:10:42 PST
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.
Comment 51 Erik Hensema 2001-10-30 08:39:06 PST
Created attachment 55743 [details]
Little screenshot of the Clear-button.
Comment 52 Francisco León 2001-10-30 12:49:12 PST
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
Comment 53 Erik Hensema 2001-10-30 13:22:15 PST
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.
Comment 54 marlon bishop 2001-10-30 15:38:43 PST
Created attachment 55831 [details]
blank modern buttons to "have a go" with
Comment 55 marlon bishop 2001-10-30 15:40:29 PST
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.
Comment 56 yatsu 2001-12-02 03:14:15 PST
Erik, any progress on this bug?
Comment 57 [not reading bugmail] 2001-12-02 05:28:08 PST
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.
Comment 58 Erik Hensema 2001-12-03 04:23:49 PST
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.
Comment 59 yatsu 2001-12-03 10:46:22 PST
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.
Comment 60 yatsu 2001-12-03 10:48:28 PST
Created attachment 60180 [details]
clear button
Comment 61 Erik Hensema 2001-12-03 12:25:42 PST
Created attachment 60197 [details] [diff] [review]
Patch against build 2001120308

Second version of the 'clear location bar'-patch.

Unpack the buttons in attachment 60180 [details] in chrome/skin/modern/communicator
Comment 62 Erik Hensema 2001-12-03 12:26:39 PST
Oh, and can someone set the 'icon' keyword for this bug?
Comment 63 yatsu 2001-12-03 23:31:21 PST
Erik, could you create a patch for Classic?
Comment 64 Erik Hensema 2001-12-04 03:57:28 PST
Created attachment 60311 [details] [diff] [review]
Patch against build 2001120321, includes 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?
Comment 65 Erik Hensema 2001-12-27 11:08:15 PST
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?
Comment 66 Jonas Sicking (:sicking) No longer reading bugmail consistently 2001-12-27 11:11:28 PST
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?
Comment 67 Erik Hensema 2001-12-27 11:24:14 PST
X-buttons are confusing, IMHO. They tend to close stuff, not wipe it.

But technically: sure, no problem.
Comment 68 Jonas Sicking (:sicking) No longer reading bugmail consistently 2001-12-27 11:27:23 PST
good point, but i would just hate to see this just sit and bitrot away just 
becuase we need an icon.
Comment 69 Erik Hensema 2001-12-27 12:00:14 PST
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.
Comment 70 Erik Hensema 2001-12-27 12:01:27 PST
Hmmm, weird. 'Accept bug' assigned it to mpt. Retry.
Comment 71 Olav Vitters 2001-12-27 13:01:26 PST
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.
Comment 72 Christopher Aillon (sabbatical, not receiving bugmail) 2001-12-27 18:48:22 PST
*** Bug 117147 has been marked as a duplicate of this bug. ***
Comment 73 Erik Hensema 2002-01-03 05:48:32 PST
Created attachment 63367 [details] [diff] [review]
Patch ported to 2002010208

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.
Comment 74 Erik Hensema 2002-01-09 14:05:13 PST
Created attachment 64189 [details] [diff] [review]
Patch against 2002010908

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.
Comment 75 Doron Rosenberg (IBM) 2002-01-09 14:18:09 PST
don't forget poor mac classic...
Comment 76 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-09 15:05:53 PST
you should probably set some defaults too. IMHO it should default to "on" on 
unix-platforms and "off" on the rest.

Great work Erik!
Comment 77 Erik Hensema 2002-01-09 15:09:27 PST
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.
Comment 78 Erik Hensema 2002-01-10 02:38:37 PST
Created attachment 64270 [details] [diff] [review]
Default preferences

Patch to defaults/pref/all.js and defaults/pref/unix.js. Clear button is
default on on Unix, off on other platforms.
Comment 79 marlon bishop 2002-01-10 10:52:55 PST
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.   
Comment 80 Francisco León 2002-01-10 11:26:05 PST
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
Comment 81 Erik Hensema 2002-01-10 11:42:36 PST
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.
Comment 82 Ben Bucksch (:BenB) 2002-01-10 12:30:07 PST
> 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.
Comment 83 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-10 12:39:17 PST
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
Comment 84 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-10 12:53:23 PST
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
Comment 85 marlon bishop 2002-01-10 13:07:05 PST
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.
Comment 86 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-10 13:16:51 PST
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?)
Comment 87 marlon bishop 2002-01-10 13:24:13 PST
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. 
Comment 88 Ben Bucksch (:BenB) 2002-01-10 13:35:27 PST
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.
Comment 89 Akkana Peck 2002-01-10 13:40:44 PST
> 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.)
Comment 90 marlon bishop 2002-01-10 14:19:31 PST
> ...
> 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 
Comment 91 Erik Hensema 2002-01-10 14:31:15 PST
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.
Comment 92 Ben Bucksch (:BenB) 2002-01-10 14:37:55 PST
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.
Comment 93 Todd Tibbetts 2002-01-10 14:39:47 PST
>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.
Comment 94 marlon bishop 2002-01-10 15:55:30 PST
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.
Comment 95 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-10 16:01:50 PST
> i am advocating we break unix convention, to maintain desktop GUI familiarity

Uh? Unix convention *is* desktop GUI familiarity on unix platforms.
Comment 96 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-10 16:58:48 PST
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".
Comment 97 timeless 2002-01-11 00:05:29 PST
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.
Comment 98 Todd Tibbetts 2002-01-11 06:19:36 PST
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.  
Comment 99 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-01-12 12:42:14 PST
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?
Comment 100 Erik Hensema 2002-01-16 03:45:00 PST
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.
Comment 101 Erik Hensema 2002-01-16 03:45:58 PST
Created attachment 65217 [details]
Screenshot of preferences window
Comment 102 timeless 2002-01-16 05:06:22 PST
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.
Comment 103 marlon bishop 2002-01-16 08:21:01 PST
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
Comment 104 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-21 05:37:27 PST
*** Bug 121078 has been marked as a duplicate of this bug. ***
Comment 105 Arthur 2002-01-21 06:20:02 PST
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)?
Comment 106 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-02-22 03:04:09 PST
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.
Comment 107 marlon bishop 2002-02-22 10:52:26 PST
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.
Comment 108 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-02-22 12:22:49 PST
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?
Comment 109 Erik Hensema 2002-02-23 06:15:43 PST
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.
Comment 110 Erik Hensema 2002-02-26 03:16:32 PST
Created attachment 71459 [details] [diff] [review]
Patch against 2002022208

Patch ported to 2002022208, ready for review.
Comment 111 Erik Hensema 2002-02-27 02:00:04 PST
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.
Comment 112 timeless 2002-02-27 14:22:36 PST
+        <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.
Comment 113 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-02-27 14:29:36 PST
Erik: IMO this should be checked in even though there is a clearing problem.
Lets deal with that problem in bug 117184.
Comment 114 Erik Hensema 2002-02-28 08:49:19 PST
Created attachment 71881 [details] [diff] [review]
Updated as per comments from timeless.

In 2002022806 the patch works fine again. No bug 117184 anymore.
Comment 115 Jesse Ruderman 2002-02-28 17:31:59 PST
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.
Comment 116 Boris Zbarsky [:bz] (still a bit busy) 2002-02-28 17:58:54 PST
> 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 117 Boris Zbarsky [:bz] (still a bit busy) 2002-03-03 11:46:34 PST
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).
Comment 118 Erik Hensema 2002-03-04 04:44:46 PST
Boris: the <image> element only has onclick, no oncommand. So it doesn't work.
Comment 119 Erik Hensema 2002-03-07 13:56:12 PST
Created attachment 73049 [details] [diff] [review]
Updated as per comments from bz

Now using a <button> instead of an <image>.
Comment 120 Boris Zbarsky [:bz] (still a bit busy) 2002-03-07 14:21:35 PST
Comment on attachment 73049 [details] [diff] [review]
Updated as per comments from bz

r=bzbarsky
Comment 121 Alfonso Martinez 2002-03-12 13:23:41 PST
*** Bug 130358 has been marked as a duplicate of this bug. ***
Comment 122 Boris Zbarsky [:bz] (still a bit busy) 2002-03-12 14:30:24 PST
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.
Comment 123 Blake Ross 2002-03-12 14:32:17 PST
This has to be hidden on Windows.  Can you attach a picture of the dialog with
the button in Classic and Modern?
Comment 124 Erik Hensema 2002-03-12 14:41:57 PST
Boris: thanks, I'll do that.

Blake: the button is hidden by default on all platforms except Unix.

I'll attach screenshots.
Comment 125 Erik Hensema 2002-03-12 14:47:07 PST
Created attachment 73762 [details]
Screenshot of modern
Comment 126 Erik Hensema 2002-03-12 14:48:04 PST
Created attachment 73764 [details]
Screenshot of classic
Comment 127 Ben Bucksch (:BenB) 2002-03-12 15:56:31 PST
That looks too much like Stop or close
Comment 128 yatsu 2002-03-12 22:36:21 PST
for a more obvious icon; take the X used in classic and place it over classic's
& modern's bookmark icon. 
Comment 129 Erik Hensema 2002-03-15 01:42:52 PST
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.
Comment 130 Lasse Marøen 2002-03-15 02:14:27 PST
Created attachment 74308 [details]
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.
Comment 131 Lasse Marøen 2002-03-15 02:17:58 PST
Created attachment 74309 [details]
Suggestion for classic

... and the same for classic. Using the red x from modern - the delete button
in classic doesn't have an x.
Comment 132 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-04 10:58:22 PST
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...
Comment 133 Erik Hensema 2002-04-04 11:22:26 PST
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.
Comment 134 Alec Flett 2002-04-04 12:09:56 PST
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)
Comment 135 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-04 12:22:08 PST
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."
Comment 136 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-04 12:30:04 PST
sorry, change "UI spec" to "toolbar customization spec" in my previous comment
Comment 137 Alec Flett 2002-04-04 13:59:43 PST
Comment on attachment 73049 [details] [diff] [review]
Updated as per comments from bz

well then! my bad.
sr=alecf
Comment 138 Asa Dotzler [:asa] 2002-04-05 11:28:25 PST
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
Comment 139 Arthur 2002-04-08 05:35:53 PDT
Erik, have you asked someone with CVS access to check the patch in? Today, we
probably branch.
Comment 140 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-08 06:02:33 PDT
I can check this in for erik.
Comment 141 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-08 06:47:20 PDT
Created attachment 78180 [details] [diff] [review]
cvs diff -u version

Patch against current cvs -- attachments 64270 and 73049 unite.
Comment 142 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-08 06:48:11 PDT
Comment on attachment 78180 [details] [diff] [review]
cvs diff -u version

carrying forth r=timeless,bzbarsky sr=alecf a=asa
Comment 143 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-08 06:53:47 PDT
Checked in.
Comment 144 Håkan Waara 2002-04-08 11:49:11 PDT
Uh, why isn't this off by default? 
Comment 145 tor 2002-04-08 11:55:20 PDT
The urlbar is already too short - please don't steal more horizontal space.
Comment 146 Arthur 2002-04-08 11:56:43 PDT
*nix default on, all others default off.
Comment 147 Christian :Biesinger (don't email me, ping me on IRC) 2002-04-08 12:00:37 PDT
>*nix default on, all others default off.

seeing this on windows too, and I have not enabled it manually
Comment 148 Ben Bucksch (:BenB) 2002-04-08 12:04:16 PDT
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.
Comment 149 Akkana Peck 2002-04-08 12:08:23 PDT
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.
Comment 150 Håkan Waara 2002-04-08 12:13:04 PDT
Why did this go into the 1.0 trunk?
Comment 151 Akkana Peck 2002-04-08 12:14:23 PDT
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.
Comment 152 Asa Dotzler [:asa] 2002-04-08 12:17:30 PDT
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.
Comment 153 Francisco León 2002-04-08 12:31:01 PDT
there is

+// clearbutton default on
+pref("browser.toolbars.showbutton.clear", true);
+
in unix.js

turning that false should fix it?
Comment 154 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 12:42:05 PDT
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
Comment 155 Mike Pinkerton (not reading bugmail) 2002-04-08 12:43:40 PDT
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?!
Comment 156 David Hyatt 2002-04-08 12:52:20 PDT
This bug did not receive any module owner review from a Navigator module 
owners or peers.
Comment 157 Jason Kersey 2002-04-08 13:16:23 PDT
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.)
Comment 158 Erik Hensema 2002-04-08 13:20:44 PDT
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.
Comment 159 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 13:26:53 PDT
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...
Comment 160 Akkana Peck 2002-04-08 13:46:10 PDT
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)?
Comment 161 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 13:52:05 PDT
yes i'm trying to fix this for all buttons, not just this one.
Comment 162 Ben Bucksch (:BenB) 2002-04-08 14:07:02 PDT
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.
Comment 163 Jason Kersey 2002-04-08 14:20:29 PDT
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.
Comment 164 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 14:26:09 PDT
Created attachment 78236 [details] [diff] [review]
makes us honor the preferenes rather then rely on localstore.rdf

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
Comment 165 Jason Kersey 2002-04-08 14:32:53 PDT
What kind of hit are we going to take on new window times for this?
Comment 166 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 14:40:44 PDT
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.
Comment 167 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 14:42:51 PDT
i don't know how this affects startup/new-window performance and i'm outside 
the NS firewall so i can't test :(
Comment 168 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-08 14:44:09 PDT
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.
Comment 169 Ben Goodger (use ben at mozilla dot org for email) 2002-04-08 14:57:59 PDT
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. 
Comment 170 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-08 15:08:19 PDT
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.
Comment 171 Håkan Waara 2002-04-08 15:13:21 PDT
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.
Comment 172 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 15:13:47 PDT
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.
Comment 173 André Dahlqvist 2002-04-08 15:21:46 PDT
This feature is broken: Go to Preferences and disable this icon. Then switch
theme and restart. The icon will be back.

Back this out.
Comment 174 David Hyatt 2002-04-08 15:22:27 PDT
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.
Comment 175 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 15:48:05 PDT
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.
Comment 176 marlon bishop 2002-04-08 15:50:30 PDT
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.
Comment 177 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-08 15:55:58 PDT
> 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.
Comment 178 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-08 15:59:18 PDT
> 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.
Comment 179 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-08 16:23:09 PDT
> 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 :)
Comment 180 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-08 18:02:10 PDT
The patch for this has been backed out on the trunk.
Comment 181 Carsten Menke 2002-04-09 01:49:56 PDT
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)
Comment 182 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-09 10:55:03 PDT
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.
Comment 183 Marten ter Borgh 2002-04-09 12:35:27 PDT
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.
Comment 184 Steve Grecni 2002-04-09 12:55:37 PDT
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.
Comment 185 Christian :Biesinger (don't email me, ping me on IRC) 2002-04-09 13:07:29 PDT
>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 :)
Comment 186 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-09 13:54:15 PDT
> 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.
Comment 187 Erik Hensema 2002-04-09 14:10:07 PDT
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?
Comment 188 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-09 14:23:08 PDT
> 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.
Comment 189 Paul Baker 2002-04-10 17:24:09 PDT
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!!!!!
Comment 190 Erik Hensema 2002-04-11 01:55:15 PDT
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?
Comment 191 Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-04-11 02:14:25 PDT
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 :-)
Comment 192 timeless 2002-04-11 05:04:55 PDT
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).
Comment 193 Jesse Ruderman 2002-04-11 06:47:24 PDT
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)."
Comment 194 Marten ter Borgh 2002-04-11 15:32:32 PDT
>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?
Comment 195 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-11 16:27:40 PDT
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.
Comment 196 Helge Hielscher 2002-04-11 17:09:40 PDT
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)
Comment 197 Jesse Ruderman 2002-04-11 19:01:10 PDT
If it's not Mozilla's place to help make Linux more appealing to normal users,
whose place is it?
Comment 198 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-04-11 20:39:09 PDT
We can't design a UI by adding every button which gets 12 votes.
Comment 199 Paul Baker 2002-04-11 21:08:34 PDT
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.
Comment 200 Paul Baker 2002-04-11 21:21:45 PDT
My bad.

s/bug#72632/bug#72623/
Comment 201 metal_17 2002-04-12 00:40:34 PDT
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!
Comment 202 P Wagland 2002-04-13 05:53:11 PDT
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!
Comment 203 Erik Hensema 2002-04-13 07:02:42 PDT
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
Comment 204 Robert Kaiser 2002-04-13 14:59:59 PDT
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...
Comment 205 Erik Hensema 2002-04-15 09:53:47 PDT
Created attachment 79271 [details] [diff] [review]
New try

This is the button with hidden="true" persist="hidden". On a new profile the
button is hidden, the user can enable it from preferences.
Comment 206 Erik Hensema 2002-04-15 09:56:41 PDT
Created attachment 79275 [details] [diff] [review]
Default preferences, again not in CVS format

Default preferences for new profiles, defaults to off on all platforms.

Patch is not in CVS format.
Comment 207 Drazen Kacar 2002-04-15 23:07:51 PDT
> 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.
Comment 208 Boris Zbarsky [:bz] (still a bit busy) 2002-04-16 15:57:14 PDT
*** Bug 137788 has been marked as a duplicate of this bug. ***
Comment 209 Thomas Dodd 2002-05-02 14:03:51 PDT
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.
Comment 210 HJ 2002-05-14 05:08:26 PDT
Created attachment 83510 [details]
just an example
Comment 211 HJ 2002-05-14 05:38:16 PDT
Created attachment 83515 [details]
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 :-)
Comment 212 Erik Hensema 2002-06-06 08:36:21 PDT
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.
Comment 213 Peter Weilbacher 2002-06-06 09:47:09 PDT
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).
Comment 214 yatsu 2002-06-06 09:52:18 PDT
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.
Comment 215 Helge Hielscher 2002-07-11 10:12:45 PDT
You can use http://diggler.mozdev.org/ until this bug is fixed.
Comment 216 Jesse Ruderman 2002-07-16 12:02:14 PDT
See also bug 76010, paste onto selected text in location bar should overwrite
instead of insert.
Comment 217 Aleksey Nogin 2002-12-21 16:21:58 PST
What's the status of this? Comment #212 (from 2002-06-06) said "expect some real
work soon", but than nothing happened...
Comment 218 César 2003-01-06 18:51:22 PST
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.
Comment 219 Daniel Clemente 2003-02-07 11:05:51 PST
*** Bug 186380 has been marked as a duplicate of this bug. ***
Comment 220 Erik Hensema 2003-02-12 03:31:14 PST
> 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.
Comment 221 Matthias Versen [:Matti] 2003-02-12 18:33:46 PST
*** Bug 193066 has been marked as a duplicate of this bug. ***
Comment 222 Alfonso Martinez 2003-03-29 03:03:48 PST
*** Bug 199765 has been marked as a duplicate of this bug. ***
Comment 223 Boris Zbarsky [:bz] (still a bit busy) 2003-12-29 15:49:57 PST
*** Bug 229679 has been marked as a duplicate of this bug. ***
Comment 224 Klaus Kusche 2004-11-15 09:59:00 PST
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.
Comment 225 Christian :Biesinger (don't email me, ping me on IRC) 2004-11-15 10:36:33 PST
or you press the middle mouse button over the content area...
Comment 226 Ria Klaassen (not reading all bugmail) 2006-01-25 06:49:54 PST
*** Bug 324622 has been marked as a duplicate of this bug. ***
Comment 227 Philipp Kolmann 2006-06-09 02:54:52 PDT
There is an Extention that adds this Feature:

https://addons.mozilla.org/firefox/2342/

HTH
Comment 228 richard brack 2007-01-30 06:56:27 PST
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.
Comment 229 Erik Hensema 2009-02-08 23:43:19 PST
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.
Comment 230 P Wagland 2015-12-19 15:32:47 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.