Closed Bug 24651 Opened 25 years ago Closed 15 years ago

button to Clear the URL field

Categories

(SeaMonkey :: Location Bar, enhancement, P3)

Product:
SeaMonkey
Component:
Location Bar
Platform:
x86
Linux
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.1alpha

People

(Reporter: buono, Assigned: erik)

References

Details

Attachments

(10 files, 13 obsolete files)

Screenshot of preferences window
11.02 KB, image/gif
Details
Screenshot of modern
11.50 KB, image/gif
Details
Screenshot of classic
3.65 KB, image/gif
Details
Suggestion for modern
339 bytes, image/gif
Details
Suggestion for classic
368 bytes, image/gif
Details
makes us honor the preferenes rather then rely on localstore.rdf
2.69 KB, patch
Details | Diff | Splinter Review
New try
4.05 KB, patch
Details | Diff | Splinter Review
Default preferences, again not in CVS format
439 bytes, patch
Details | Diff | Splinter Review
just an example
946 bytes, image/gif
Details
screendump
22.05 KB, image/jpeg
Details 
A good feature that I have never seen would be a button by the navigation
buttons that would clear the web address field...rather than selecting and
deleting which is very clumsy.
rfe/help wanted for some one that wants to fiddle with xul?
Assignee: chofmann → don
Summary: Clear the URL field → RFE: button to Clear the URL field
Hmmmmm ...
Summary: RFE: button to Clear the URL field → [RFE] button to Clear the URL field
Target Milestone: M20
Move to "Future" milestone.
Target Milestone: M20 → Future
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
leger is no longer @netscape. changing qa contact to component's default
QA Contact: leger → chofmann
I can't see this as being useful.  We have many other bugs on making selecting 
the contents of the URL bar easier and quicker, and that would make this less 
`clumsy'.  Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Component: Tracking → XP Apps: GUI Features
QA Contact: chofmann → sairuh
Resolution: --- → WONTFIX
verified.
Status: RESOLVED → VERIFIED
*** Bug 81867 has been marked as a duplicate of this bug. ***
Blake: You marked it invalid AND verified it.
The RFE is very relevant for *NIX type systems though, where auto-copy takes
place on selection. Reopening for reconsideration.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
-> UI Design
Assignee: vishy → mpt
Status: REOPENED → NEW
Component: XP Apps: GUI Features → User Interface Design
QA Contact: sairuh → zach
This is a *nix specific feature, and a very useful one. Get a copy of Konqueror
and watch it work.
It is very frustating to delete the url with the backspace key one key at a
time, or to delete it all first, then copy the url, and then paste it. That
would be a workaround, but nobody wants that :)
A clear button is unnecessary. Just middle-click a non-link/widget part of the
content area (instead of middle-clicking the URL bar). I recommend rejecting
this RFE since it would introduce unnecessary UI clutter.
A RFE well implemented would introduce no clutter at all. See that little  pen
on the left of the http? Just implement a right click function that erases the
urlm or even faster yet, just erase it with a left click. How many lines would
it take to do this? I think less than five, and i am being generous :)
OS: All → Linux
Target Milestone: Future → ---
Mozilla is not 4xp. For one, NC4.* will not paste to SAME window when clicking
on content area.

Another thing is that mozilla doesn't lock mouse-scrolling on a middle click
mousedown. (NV4.* locks it.)

This means that in mozilla, whenever i "slip" and scroll one line after
mousedown: when mouse-button is released i wind up pasting whatever is on
cliboard to the URL field, sending me off to Google instead.

To avoid further dataloss i simply had to disable the content-area paste feature
with user_pref("middlemouse.contentLoadURL", false);

This RFE is a valid request.
I tested the IRIX and Solaris versions Netscape Communicator 4.7x. In both cases
middle-clicking the content area loads the URL in the window whose content area
was clicked--as in Mozilla.

Middle-clicking WFM. Do I understand correctly that you are having problems with
a wheel mouse? Wouldn't it make sense to address those issues directly? Also,
invoking a search engine could be prevented by performing an URL-likeness test
on the clipboard contents. (If you drag&drop a selection that contains spaces
onto a Mozilla window on Mac OS Classic or on Mac OS X, Mozilla just ignores the
drop.)
I have adressed the problem Ad Nauseatum. For insight on the pasting problem
that lead up to the pref i refer to, read bug 57317 and dups.
In particular see comment from Akkana 2001-01-08 10:47 

I also filed an RFE bug 64577, in an attempt to make the current behaviour less
annoying.

But this all still doesn't make this RFE invalid. I would like it as a feature -
very much.
I have an intellimouse explorer, and more than one time i have been scrolling
and then accidentaly clicking on the middle mouse button (the wheel is there)
and thus sending me to another website on the clipboard. It's very annoying ,
though i know how to disable it. You know it, i know it, but grandma doesn't,
and you should be aiming for user-friendlyness

Like i said, i think this would not even take 5 lines of code, and would be easy
to test in one of the everyday night builds
Yay, the silliness of select-to-copy strikes again.

I think that an `Open' button on the toolbar, as used in Navigator 3.x and 
earlier, would be a much less hacky solution. Of course it would be off by 
default, but Unix users could use it to open URLs quickly.
Maybe we dont need there to be a large clear button.  Something Small and 
simple.  Maybe a function added to the menu that pops up when you right click 
in the url window.
Why are you guys making a simple thing look so complicated?
The button is already on the UI. The little paper and pen left of the http://
would be the button to use. Just make it erase the url when you left click on
it, or right click on it and choose "delete url" off a menu. That's all it would
take!
mpt, middle-click paste is not that silly if you compare it to drag&drop instead
of comparing it to copy-paste.

Left mouse down on the little icon (it is supposed to be a bookmark--not a pen)
is reserved for starting dragging it. The context menu already includes an item
called "Delete", but it requires the URL to be selected. It would be logical to
make the context menu of the icon apply to the URL field even when nothing is
selected, since drag actions performed on the icon apply to the entire URL. Then
"Paste" could be expected to replace the URL bar contents.

(Of course, the URL bar can be cleared quickly by pressing Ctrl-L and then
backspace.)
Actually i did not know the ctrl-l trick. Since it's the keyboard that does the
url highlighting and not the mouse, it can be erased with that trick and paste
the url on the clipboard and it works

So i will take it as a valid workaround
Thanks
The little icon you reference is a drop source. overloading left click to 
_kill_ the data it is supposed to source is *BAD*. Right clicking it to clear 
otoh /might/ be ok.
P3.. hmm..

Consider each movement an imaginary pain. Why wrestle a keyboard unless you have
to? Typing is bad enough. Mozilla is a GUI based application. When I
copy/paste/scrollwheel etc. in X, my hand is on the mouse the whole time. I am
Extremely lazy when it comes to computers. Lazyness is a major incentive behind
many a great invention.

So I use the keyboard to issue commands only when it takes me less time than
doing it via the GUI. I use ctrl+X/C/V if I'm already typing something. But when
using the browser i am mostly reading and clicking. So my hand is on the mouse
then. If i must key a three-key combo sequence on the keyboard in order to
prepare for pasting, I would have to remove my right hand from the mouse, put
out the cig to avoid dropping ashes on the keyboard, remove my left hand from
the coffee-cup, key in whatever, then grab cup, cig and mouse again and THEN
paste, wheel, click - or whatever I was doing. It's a whole little marathon.
I know this is not an important rfe, but it's easy to do and improves
user-friendlyness. If i would be familiar with mozilla's code (or c++ code
altogether- i am a rookie) i would do it myself
Adding one more button to the toolbar is a much bigger 'imaginary' pain for 
many users, as it adds unnessary visual complexity with questionable benefits 
in usability. This looks like a hack to me.
Eye-movement does not burn as much calories as moving two arms.
This is about ease of use. As already commented here, the interface could be
incorporated into the existing interface - no extra clutter.

Does anyone object if I resummarize: "Context menu of URL bar proxy icon should
apply to entire URL (not selection)"? Based on the previous comments that would
be a more accurate summary.
i think the current summary is fine.

The main idea is the need for a quick CLEAR function for the URL field. It could
be done via context menu, but if visual clutter is an issue: why not simply let
it perform in silence when right-clicking url bar down-arrow?

That would also make it a "one click" thing, which is the best solution.
From a context-menu it would take two clicks.
Right clicking has a predefined meaning.  Overloading its meaning should not 
earn you many friends [in English: don't do that].

Ok, so here are some options:
middle click on ...
* ... url proxy to
 a. Clear url
 b. a+paste clipboard content
 c. b+go to new url
* ... non selected urlbar
 a. Clear url
 b. a+paste clipboard content
 c. b+go to new url

But to be honest, instead of spamming this bug, someone should open a thread in 
npm.unix or .xpfe or .gtk or ... asking for proposals and comments on current 
proposals.  Keep in mind that right click and left click already have well 
defined semantics.

mpt: you may be the default owner of UID, but as you are not an X11 user you 
have no business owning this bug, can you try to find someone who does?

blake: my comment to mpt would apply equally well to you.
This RFE would be covered by mpt's Paste&Go menu item idea, wouldn't it? (As in,
right click on the location bar, and choose "Paste & Go" which replaces the 
contents of the location bar with the clipboard and goes there).
I don't know what you're trying to accomplish here, but Matthew has every right 
in the world to own this bug.  If a UI designer had to have firsthand 
experience with and in-depth knowledge of every interface she designed and 
commented on, she'd be very busy, and very slow.

I've seen Matthew give some of his best UI advice on topics that he's not 
intimately familiar with, and it makes sense.  He's in the best position to 
judge the idea impartially, on its merits.  All he did so far in this bug was 
think aloud.

As for your comments to me, they're nonsense.  The development portion of this 
bug belonged in XP Apps: GUI Features, and I WONTFIX'd it (a resolution I still 
stand by).  No one complained, and over three months later.  Over a month 
later, someone finally did, so I passed it over to UI Design, where it now 
belongs.  I don't own the bug, and don't know what you're talking about.

There is no need to be so dramatic ("you have no business..."), to cc 
mozilla.org staff.  Nothing here involved unusual process, it was all textbook 
Bugzilla procedure.  You've done this in multiple bugs now; no one benefits 
from it, and it's just distracting.

Well... if anyone wants an ugly amateur fix:

I found i didn't need the current usage of function handleURLBarRevert() - never
use it - so i modified it to clear the text instead by simply adding
gURLBar.value = ""; on a line below gURLBar.select();

Files:
mozilla/xpfe/browser/resources/content/fastnav.js and navigator.js

When urlbar has focus, hitting Esc key will then clear the current text and
allow you to paste whatever with a middle button click. Seems to work fine.
Akkana: I seem to recall there is (supposed to be) a pair of
emacs-/WordStar-style keybindings which you can use consecutively on Unix to 
clear the address field. Is that correct?

Francisco: Yes, I see Konqueror's clear button in a screenshot
<http://www.konqueror.org/pics/konq_navigate.png>. It looks like a pirate flag, 
and is not obviously related to the address field itself. I also see several 
other egregious UI faults in that screenshot, including renaming the `File' 
menu to `Location' (contravening KDE's own UI guidelines), failing to put the 
`Back' button in its usability-maximizing position at the left end of the 
toolbar, and having about 50 percent too many menus for a Web browser. So, er, 
I wouldn't exactly rely on Konqueror as a shining example of good UI design.

R. K.: It could be the wrong time of day for me, but `the interface could be 
incorporated into the existing interface - no extra clutter' doesn't make any 
sense at all. If you have more controls in the UI, you have more clutter by 
definition. Yes, I know it's just `one extra button', but so is the `Add 
Bookmark' button which someone wanted to add to the address bar. And the `Load 
Images' button. And the `Copy' button. And ... and ... and ... You will have 
the opportunity to add (and remove) buttons once Mozilla has a customizable 
Toolbar, but I still see nothing here which a `Clear' button would do that an 
`Open' button would not do just as well or better (not to mention `Open' being 
3xp).

Timeless: Bite me.

Hixie: `Paste & Go' dates from when I was young and innocent and thought there 
shouldn't be a Go button in Mozilla, and was dreaming up all sorts of creative 
ways to avoid it. Then I watched (and ended up having to help) many real users 
trying to get to a Web address without the `Go' button, and I saw the error of 
my ways.

If no new and convincing arguments appear in the next week, this bug is 
probably headed on the return journey to WONTFIX land. (Provided that the 
Powers That Be decide I'm allowed to do that, of course.)
I searched through the existing "emacs'ish" keybindings, but didn't find any
incorporated that did what i want. There's likely something available in emacs
though - i don't know it well.

Regarding clutter: I meant the *function* could  be incorporated into existing
interface. In other words be invisible. Sample implementations would be to make
urlbar clear when user middle or left-click the arrow in urlbar.
Or a user-pref to make ESC clear urlbar instead of revert. For my own use I've
found a stupid hack that does the trick, but for the rest, a real implementation
would be nice. I believe it is the need for a function rather than a button that
is the real issue of this bug.
I think the "file" menu being called "location" on kde is not something to see
as a bad thing. You say something about so many menus, and so i counted them.
Mozilla has 10 and konqueror has 9. I hope you guys remove the QA and Debug
menus inside help, or delete them once mozilla reaches 1.0 status

Anyway, the konqueror thing was only to have a reference of what could be done
to resolve this RFE if we would vote to make an additional button, which i think
we all believe it's unnecessary clutter. So, we have made our points clear and
we still are waiting for implementation of a solution.

Ironically, i posted this rfe not so long ago, and i saw that it was made a long
time ago (this bug) and has never been worked in. Now i learned that doing a
ctrl-l and backspace would erase the url, so i am happy with this workaround.

I still think the best thing to do , if any, is to implement a function in the
bookmark pen (left of the url) to have a "erase url" on the menu when doing a
right click on it

So, can we do a vote on this and start to work? To my belief we have 3 choices
1.-New button ala konqueror (i think nobody wants this)
2.-Right click "erase url" on bookmark pen left of the url
3.-Simple keybinding on url "Esc" erases url 
If you want to use the mouse only, you can do: File|Open Web Location. The
textfield in the upcoming dialog is empty, so you can do the X-paste.

If you just want to open the URL in the X "clipboard", you can paste it into an
empty area in the browser canvas, this will load it. (In my opinion, the "proxy
icon" (the bookmark icon next to the urlbar) should be the area which behaves
that way, and the only one.)

I'm not getting through here. I give up.
Uploaded a little something with how to modify ESC if anyone is interested.
http://home.c2i.net/dark/My_Mozilla_FAQ.html
In answer to Matthew's earlier question: ^U deletes the current line; so does
^A^K (beginning of line/delete to end).  Of course, you have to get focus there
first if it isn't already there (accel-L).  So accel-L ctrl-U is the fast way to
do this on Unix.
Someone changed something in the URL field.
Now i can press ESC instead of ctrl-l so i can DEL the URL field
I am happy with it, besides i am now used to pasting url's in the browser window
directly
If it was up to me i would close this

*** Bug 88093 has been marked as a duplicate of this bug. ***
*** Bug 89364 has been marked as a duplicate of this bug. ***
This could probably be useful in windows also, though for a different reason.
Have you ever watched a novice computer user type an url? I've seen lots of
people click the url bar giving focus to the current url, then instead of just
typing the url they use right arrow button to move to the end of the text, then
hit backspace several times until they are left with http://www. 

I like the suggestion by Francisco Leon - to use the icon before the url to
provide a dropdown, although I think it should provide several options, like:

[blank]
http://
http://www.
ftp://

Maybe it could even be customisable in the prefs, so you could put in your most
used links in the dropdown list.

Another possible solution: make clicking on the location bar select its 
contents on Linux, like it does on Windows.  In addition or alternatively, make 
middle-clicking on an unfocused location bar replace the URL rather than 
inserting into the URL already in the location bar.
I too am frequently annoyed at having to clear the location bar through a means
that loses my last selection, usually the url that I want to paste. This is one
of those "damned, Mozilla would be so much more usable if it wouldn't do that"
inconvenieces that is just too trivial to others to think about.

I have spent a brief time in the KDE 2.2 beta, and used Konqueror. I immediately
found the "Clear Location Bar" button and find myself using it time and time
again. No exaggeration, I actually found it a very useful feature.

The advocacy over, let's look at what's been said. mpt says that by definition,
another button brings clutter, which is in these circumstances, a bad thing.
Well, we need to come up with a viable solution. FWIW, I found Konqueror's UI
very good, buttons were where I anticipated and I worked very quickly and easily
with them. I don't claim to be representative of Fred and his friends, but
that's my opinion.

It's been suggested that there are a number of solutions:

1. Right-click in the urlbar, hit a new item, "Paste and Go" or similar. You
have to find it, and then remember to use it. That means effort. Effort means
users won't bother using it unless they believe it is reasonable for them to do
it. Chuck that idea out of the window then, but tie to some string so we can
retrieve if we're desperate.

2. File>Open Web Location. User has to click to get into the menu, select the
right option, wait for the dialog to open,  paste the url into the right text
box, then hit OK or whatever. Way too long for the average user. For bookmarks,
fine, but the user expects to access a web url by entering into the url bar, not
via menus. Chuck that idea out of the window.

3. ctrl+l, then hit Delete or Backspace. Brilliant! Excellent. But hang on, only
1% of users who bothered to find out will ever know it exists. Oh well. Out of
the window with that.

What are we left with? Oh, a button. Where should we put it? Oh, this bookmarks
drag-n-drop thingy is in the way, hrm, does anyone actually use that thing? I
certainly don't, but I'm sure Netscape will pull a few hundred users out of a
hat who they claim do use it... So, we're left with modifying what we have
really cleverly then.

Jesse: your last suggestion about making the selection of the text in the url
bar *not* overwrite the clipboard contents is fine, and does work on Windows,
but unfortunately 99% of people on Unix will select the contents of the url bar
to get that url into the clipboard. Nice try though.

Unfortunately, I don't have an answer here, either. I do have a couple of
suggestions, though, both of which fall into various traps. I'm sure you can
guess what they are respectively:

1. New menu: File>Clear URL
2. In the URL Bar's drop-down history list, have a "<blank entry>" item right at
the top. Have that entry there whether history is switched on in preferences or
not. Click it, and be ready to enter your url in the newly blanked url bar. I
quite like this one...

Well, they *might* work...

My suggestion wouldn't make it any harder to get the URL into the primary X 
selection.  To focus the URL bar to start typing, click once, which would 
select the contents of the URL bar but not copy them.  To copy to the current 
URL, select it with a drag motion, like you probably do now.  (See bug 62495, 
clickSelectsAll should not trigger if you're selecting text.)
> which would select the contents of the URL bar but not copy them

That would be too confising for users, IMO. (If it is consistent with other X
apps at all.)

Not to mention contrary to expected behaviour. I still say we need a button,
after all, the majority of Linux users tend not to know how to Copy/Paste the
first few times, so it's really infuriating for Mozilla to clear the selection
right when you want to paste an alternative selection.



    
    

    
  
The patch I've attached is against the nightly build of 29 oct 2001.

It adds a 'Clear' button left of the location bar. By default the button is
turned off but it can be switched on in preferences.

It currently is only localised for en-US and only works for the modern theme.

IMHO the button should be a small icon instead of the word 'Clear', but since
I'm no graphics artist and this is a proof-of-concept I settled for the text.

    
    

    
  

      
      
      
      

        Attached image
          
        Little screenshot of the Clear-button. (obsolete)
        — 
      

    


  

    
    

    
  
Nice button, it adapts really good to the skin, bad thing is that it is too big
and i bet i will be rejected (i would)
Go to http://www.konqueror.org/pics/konq_about.png and look at how konqueror
does it. Really small, no clutter. An X is really intuitive, and the caption
above the button makes it work for beginners. You are on the right track and i
know you can do this Erik

    
    

    
  
Yes, it does need to get smaller. I just need to dig deeper into XUL to achieve
that, because I think I have to define a whole new button-class. Currently this
is too much work for me, but someone with more xul experience than me could
implement it in a matter of minutes, I think.

Besides, I wouldn't know what icon to use. Really: what icon would be small
(about the size of the bookmark-icon in the locationbar) and yet be meaningfull?
I don't know, but maybe that's because I know next to nothing about UI design.

So: any takers on this one? First we need an icon and next we need a smaller
button to place it in.

    
    

    
  


  

    
    

    
  
if you can come up with an icon, try applying to these buttons (act, hov, normal).  then place the button inside of the url "groove" which 
surrounds the url box.


    
    

    
  
Erik, any progress on this bug?

    
    

    
  
over here at: http://www.geocities.com/pratiksolanki/

see:

// The following pref will disable selecting the entire URL when you
// click in the URL bar. The default is true. (double clicking on the
// URL will still select the entire URL for you).
user_pref("browser.urlbar.clickSelectsAll", false); 

it should be helpful for some people here.

    
    

    
  
Progress: I tried porting my code to moz 0.9.6, but it segfaults on it. When
I've got time I'll look into it again.

I haven't been able to design nice looking buttons. I'm just no graphics artist.
Someone else will have to do that.

I'll try to make a patch to moz 0.9.6 or some recent nightly build and I'll
attach it to this bug, whether or not it's in a working state yet.

    
    

    
  
Let's just keep it simple :) Really, a simple X will do. Although it'd have to
be a graphic otherwise it'd look out of place.

Attaching an example. You might be able to use it, or not. I doubt it, but not
sure if there are any legal issues. I'll send a mail to the sylpheed developer's
list to findout if this is permitted if you decide to use it.

    
    

    
  

      
      
      
      

        Attached image
          
        clear button (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch against build 2001120308 (obsolete)
        — 
          — Splinter Review
      

    


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

Unpack the buttons in attachment 60180 [details] in chrome/skin/modern/communicator

    
    

    
  
Oh, and can someone set the 'icon' keyword for this bug?

    
    

    
  
Erik, could you create a patch for Classic?

    
    

    
  


  
This is basically the same as yesterday's patch, but this one includes the
classic skin. You can unpack the blank buttons in the classic directory but
they'll look horrible.

skin/classic/navigator/navigator.css was missing from chromelist.txt, so I
brute-forced it into patchmaker. This means the CVS equivalent of this file is
missing from the patch.

marlon: could you attach some blank classic buttons too?

    
    

    
  
The patch broke in recent builds (somewhere between dec 21 and dec 27).

It doesn't apply cleanly (which is easily solvable) and clearing the location
bar broke because in the `gURLBar.value = "";' in navigator.js is now ignored
(NULL strings are ignored).

Anybody know how to solve this?

    
    

    
  
btw Erik. There are now *two* X buttons in the tree. One to close the sidebar 
and one to close tabs. Couldn't you use one of those?

    
    

    
  
X-buttons are confusing, IMHO. They tend to close stuff, not wipe it.

But technically: sure, no problem.

    
    

    
  
good point, but i would just hate to see this just sit and bitrot away just 
becuase we need an icon.

    
    

    
  
Me too, and I won't let that happen. I can't live without the clear button
(really, I can't) so the patch will be maintained for as long as needed.

However, I also don't want to submit a patch which is going to be rejected
because of UI issues.

I rather wait a bit longer for a nice icon. Maybe I'll try to create one myself
next week. I'm free for the hollidays now.

I'll also assign the bug to me.
Status: NEW → ASSIGNED

    
    

    
  
Hmmm, weird. 'Accept bug' assigned it to mpt. Retry.
Assignee: mpt → erik
Status: ASSIGNED → NEW

    
    

    
  
Erik: 'Accept bug' means that the current bug owner has accepted the bug. You
currently have the required permissions to determine that for someone else :)

When you reassign a bug, the bug State changes to New/Unconfirmed.

As you clearly want this bug, accepting the bug for you.
Status: NEW → ASSIGNED

    
    

    
  
*** Bug 117147 has been marked as a duplicate of this bug. ***

    
  
Depends on: 117184

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch ported to 2002010208 (obsolete)
        — 
          — Splinter Review
      

    


  
The patch ported to the lastest nightly.

This doesn't actually clear the location bar, but places a space (" ") in it,
because of the recent location bar API change.

Hopefully I'll find time to work on the graphics tomorrow.

        Attachment #55715 -
        Attachment is obsolete: true

    
  

        Attachment #55743 -
        Attachment is obsolete: true

        Attachment #60197 -
        Attachment is obsolete: true

        Attachment #60311 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch against 2002010908 (obsolete)
        — 
          — Splinter Review
      

    


  
And there it is. This patch uses the close buttons from the standard tree. IMO
they look really nice, and not confusing to the user as I was afraight of.

This patch is ready for review.

    
  

        Attachment #55831 -
        Attachment is obsolete: true

        Attachment #60180 -
        Attachment is obsolete: true

        Attachment #63367 -
        Attachment is obsolete: true

    
    

    
  
don't forget poor mac classic...

    
    

    
  
you should probably set some defaults too. IMHO it should default to "on" on 
unix-platforms and "off" on the rest.

Great work Erik!

    
    

    
  
Anybody willing to help me on the Mac classic skin? I haven't got a Mac and I'm
utterly clueless on how to make a patch without it.

Removed 'icon' keyword.
Keywords: icon

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Default preferences (obsolete)
        — 
          — Splinter Review
      

    


  
Patch to defaults/pref/all.js and defaults/pref/unix.js. Clear button is
default on on Unix, off on other platforms.

    
    

    
  
i don't agree with adding this button.  the claims that it improves usability
are not substantiated  (other than, "Konquerer has it" which is not evidence of
usability).  A button's availability does not equate so simply to usability;
rather, in most cases it becomes a hinderance.  

Currently, clearing the URL field, which is the desired task, is accomplished by
overwriting the existing field contents (full text select), after focusing the
field.  [Double click] inside url field provided the same full text select.
Therefore, our existing behavior today provides the same result as adding a
"clear" button would.  Thus, adding any clear-like mechanism (button) would add
redundancy when 1)it is not necessary for this task, and 2)contribute to toolbar
clutter 3)decreasing URL field real-estate.  

2) and 3) aside, i also feel that this button would contribute unnessecary
weight to toolbar customization and/or prefs, because its redundant value offers
practically no improvement (off or on default), in any scenario, to completing
the task of clearing the URL field. 

Users understand:  -> select(click/focus) -> overwrite.   

    
    

    
  
remember that selecting the text in the url bar overwrites the clipboard, which 
is annoying when you are copying and pasting links in the urlbar, however 
middle clicking in the browser window is fine for me

    
    

    
  
Marlon: the goal of the button is not to clear the location bar, but to clear it
without copying its contents to the clipboard. This is because said clipboard
sometimes holds the URL you want to copy to the location bar.

On Mac and Windows this isn't an issue, on these platforms the button won't be
very useful, I think. However I'm addicted to it on Unix ;-)

Pasting an URL using middle-click isn't known to many people I think. A clear
button is simple and clear.


    
    

    
  
> middle clicking in the browser window is fine for me

This "feature" has other severe usability problems (apart from discoverability),
so we shouldn't rely on it. I'm not arguing for the clear button, just against
that load-by-middleclick-paste.

    
    

    
  
I would say that the button takes care of more problems then just being able to 
go to url in the clipboard. If you just want to type an url it is IMHO pretty 
bad to have to give up the contents of the clipboard (or manually deleting char-
by-char the current url).

So what we need is a way to clear the contents of the url-bar, and i can't 
think of any more user-friendly way then a button. Magic mouse-buttons or 
special keycombinations isn't enough for stop or reload, so why should it for 
clearing the urlbar, which i would think is done just as often

    
    

    
  
Unless, of course, we always clear the urlbar on focus. And restore the url on 
unfocus (unless it has been changed). Since you far more often want to go to a 
compleatly different url then edit the url you're at.

But IMHO the clear-button is more user-friendly

    
    

    
  
As i am somewhat unfamiliar with Linix/Unix form conventions, my next question
is, does this platform traditionally offer a "clear" button on every form field
to alleviate this? 

Mpt mentions, that there is a key command to clear fields.

    
    

    
  
Somebody more familiar with *nix will have to answer that.
However the urlbar is somewhat exceptional in that that you very often change 
the value in it, and most of the time to a complealy new value. In most 
textfields you enter a value in a blank textfield, or you modify the existing 
value (contrary to enter a compleatly new one)

To be honest i don't really understand what the fuzz is about. I would think 
that the clear button is used almost as often as back/forward and more often 
then stop/refresh, and noone is questioning their exsitance (or?)

    
    

    
  
since the auto-copy-on-select convention is quite foreign to prevelent desktop
GUIs, there's not much we can establish except consistency. Consistency with the
linux platform, and consistency across the other platforms we're on.  This means
no button, and overriden clipboards.  We can't be expected to solve every *nix
UI problem with our product. If Linux users currently live with overridden
clipboards routinely, then why should we be different?  We shouldn't sway from
the convention, because that in itself is bad practice.  I don't myself know the
circumstances surrounding the feature, so have no ground to change it.

However, i would like to know if there was a way to override auto-copy-on select
function - and offer a pref to turn back on.  This would establishes Mozilla as
GUI user-friendly, without totally sacrificing platform conventions.  

The button is still a bad idea regardless of platform. 

    
    

    
  
Other suggestions:
- Context menu item for selections on editable textfields. (Sorry, if I said
that already.)
- Add special code to clear urlbar just before paste using middleclick.

    
    

    
  
> Unless, of course, we always clear the urlbar on focus. And restore the url on
> unfocus

Argh!  Many of us frequently edit the urlbar (e.g. to go up one level), or
doubleclick the url in order to paste it into some other app.

>  does this platform traditionally offer a "clear" button on every form field

No.

> Mpt mentions, that there is a key command to clear fields.

ctrl-U

> However, i would like to know if there was a way to override auto-copy-on select
> function - and offer a pref to turn back on

Yes.

user_pref("clipboard.autocopy", false);
turns off autocopy.
pref("browser.urlbar.clickSelectsAll", true);
makes a single click in the urlbar select everything (without autocopying)
whereupon you can hit delete or accel-V to paste or whatever.
Also, ctrl-L shifts focus to the urlbar and selects the whole thing, without
autocopying.

So there are already numerous ways to get this functionality, though none of
them are very discoverable.

(I'm neutral on the button myself, so have been trying to stay out of the
debate; I expect I'll turn it off myself because I don't want to lose urlbar
real estate, but if other people want it it doesn't bother me.  I have no idea
what percentage of unix users would be happy to see it, and unless we do
usability testing we'll probably never know the answer for sure.)

    
    

    
  
> ...
> So there are already numerous ways to get this functionality, though none of
> them are very discoverable.

I am not worried so much about discoverability.  We actually want the reverse. 
The desired result is that *nix users realize autocopy is turned off on the URL
field.  This they'll discover through ordinary use, the first time they attempt
use the field in the conventional desktop GUI way, copying and pasting.   Users
who are troubled by the behavior will likely have the notion to look for a
preference to reset it. we could oblige them with a pref in the "Smart Browsing"
panel, "Enable unix-style Autocopy" check box. or elsewhere.

we can't clear the URL bar on focus that's far too destructive 

    
    

    
  
The location bar is an input field one often copies text to. URLs from an
external mail program, user documentation (which often is in plain text), IRC,
etc, etc.

Other input fields are used less often or are default empty (in my experience).

Changing the copy/paste behaviour on Unix would be counterintuative: why would
Mozilla be the only Unix app which has Windows-style copy/paste?

As a matter of fact, I like Unix copy/paste behaviour in most cases. No need to
touch the keyboard at all (and that's why I've also got the 'go'-button enabled).

------

Doron: AFAIK my patch doesn't touch platform-specific bits of the skin, so there
wouldn't be a need to seperately patch the Mac classic skin.

    
    

    
  
marlon, select copies on Unix. That's the way it works, the "convention", be it
inferiour or not. I'd consider an app that doesn't do that broken, and no pref
would be able to convince me of the opposite.
Note that people do copy from the urlbar on other cases, too.

marlon, this bug does not have to influence other platforms. We can pref the
clear button and default to on on Unix and off on other platforms.

    
    

    
  
>We can't be expected to solve every *nix UI problem with our product.This is not a UI problem.  In fact, I am an ex-Windows user that is now annoyed everytime I use Windows and *cannot* copy on select.Pure and simple, the lack of a clear button keeps me from using Mozilla.  I install every new build, play with it, and end up going back to Konqueror yet wishing it had all the neat features Mozilla has.  Why?  Because the lack of a clear button drives me crazy.As for the middle click to paste a URL, that is a nice feature.  It still does not solve the problem of pasting in a URL that you then want to edit (when for example you copy a deep link but want to just go to the main page.)This is a simple request for a button that Unix users are telling you has become an essential part of the browser UI for them.  They have even gone so far as to implement it themselves and keep the patch updated to the current build.  The response seems to be "Windows doesn't need it, and a UI that behaves differently than Windows is by definition broken and does not deserve special functionality."  That seems to me a very bad mindset for a multi-platform browser.

    
    

    
  
i am advocating we break unix convention, to maintain desktop GUI familiarity,
considering the high frequency of clipboard operations and text editing this
particular form field recieves  (user ability to paste into the URL field would
be hindered). while i don't consider the autocopy function to be particularly
clever, no matter how users have come to rely on it, I realize the harm in
completely killing it. which is why i think unix people would find it useful to
toggle as a pref.  and this pref should not appear on non *nix platforms - Mac,
and Win. 

Principally, clipboard contents should not be so easily wrestled away. Users
rely on the clipboard to carry data around, and text editing should not be
allowed to disrupt that task. 

Frankly, i'd yield to you unix citizens on whether the pref is off or on by
default; however, not to adding another toolbar button.

    
    

    
  
> i am advocating we break unix convention, to maintain desktop GUI familiarity

Uh? Unix convention *is* desktop GUI familiarity on unix platforms.


    
    

    
  
Actually, I would argue that a clear button can be usefull on other platforms 
too. The process of selecting the content of a textfield is something that (at 
least on windows) is something that is non-standard. So many "mom-users" 
unfamiliar with this end up unselecting the contents again and delete the 
contents char-by-char. For these users a clear-button would be usefull.

I'm not arguing that the clear-button should default to on on other platforms 
then unix, or that we should stop select-on-focus'ing, I'm just trying to give 
additional arguments for having the clear-button.

I just can't see any arguments against it. That it clutters the toolbar doesn't 
hold, it adds no more clutter then "stop" or "refresh".

    
    

    
  
DIE.

Todd Tibbetts, congratulations, your Comment #93 managed to be unreadable in 
both mail and browser because it was prefixed by a > and contained no line 
feeds.  I'm going to post this w/ nc4win because if i used QNXVoyager i would 
probably accidentally post w/o line feeds.

first of all, don't feel that we're just giving unix users a hard time. There's 
a patch for password protected profiles which i think is actually getting more 
resistance from more people than this silly bug (whether they are equally silly 
is probably in the eyes of the beholder).  I should probably give a brief 
synopsis of that bug: At startup the user has to enter a password to open a 
profile. The password doesn't protect or obscure any of the data in the 
profile, it just exists to ask you for a password (akin to having no password 
on your computer except for your screensaver).

You should be able to right click the urlbar and select delete without 
triggering the click to select clobbers cutbuffer.

Things not mentioned. File>Open [Location] should pop up with an empty url 
field which people can use.  That dialog could probably be modified so that 
instead of closing when you click open it would tell the browser to load the 
page and then clear it[the dialog']s location field.

Aha, there it is, Comment 18. Perfectly sane.  Why can't ... oh never mind.

    
    

    
  
Why thank you timeless.  I intentionally left out all the linefeeds just to
thwart you.  :)  Was not going to clutter with a re-post, but here you go.


>We can't be expected to solve every *nix UI problem with our product.

This is not a UI problem.  In fact, I am an ex-Windows user that is now annoyed
everytime I use Windows and *cannot* copy on select.Pure and simple, the lack of
a clear button keeps me from using Mozilla.  I install every new build, play
with it, and end up going back to Konqueror yet wishing it had all the neat
features Mozilla has.  Why?  Because the lack of a clear button drives me crazy.

As for the middle click to paste a URL, that is a nice feature.  It still does
not solve the problem of pasting in a URL that you then want to edit (when for
example you copy a deep link but want to just go to the main page.)

This is a simple request for a button that Unix users are telling you has become
an essential part of the browser UI for them.  They have even gone so far as to
implement it themselves and keep the patch updated to the current build.  The
response seems to be "Windows doesn't need it, and a UI that behaves differently
than Windows is by definition broken and does not deserve special
functionality."  That seems to me a very bad mindset for a multi-platform browser.  

    
    

    
  
So how does a command qualify as a button, since we _do_ have other buttons 
which qualified somehow? 

The fact that the command is used very often? That some/many/most/all other 
browsers have buttons for the command? That it is obvious to the user what the 
button does? All of the above? Something else?

    
    

    
  
Right, so where do we go from here? Some people want the button, others don't.

I can easily produce a patch which makes the button default off on all
platforms. The only thing a user will notice is a new pref, which isn't very
intrusive, IMHO.

I'll attach a screenshot of the pref-window. Does it need any reordering? I just
took the empty spot at the end of the list.

    
    

    
  


  

    
    

    
  
mpt is currently end running around this with his spec for customizable 
toolbars.  the result is unix users will loses support for clicking to edit 
followed by pasting.

    
    

    
  
Erik, i think your screenshot proposal is fine.  When toolbar customization
arrives, this pref item, as will others on that panel, will become part of the
new design.  Be sure it is off by default for all platforms, except - Unix users
decide whether it needs to be on/off by default

    
    

    
  
*** Bug 121078 has been marked as a duplicate of this bug. ***

    
    

    
  
As a *nix using and win-machines administrating being, I vote for the button to be
available on all platforms via preference. *Lots* of people I watch actually click
several times into the URL bar until the URL is deselected and then they remove it
by hitting backspace and delete lots of times. It does help telling people in
about 50% of the cases, the others just go on with it. And btw, I love copying on
selection, this saves lots of time. 

What I would like to know from the UI-people 
is where the button should go. Is left of the URL bar the right place? Or should 
it be *in* the URL bar (like the proxy and the drop down icon)?

    
    

    
  
marlon: is the toolbar customization that you talk about in comment 103 the 
same as the one being talked about in bug 22056, which if I've understood you 
right, has been pushed for now?

If so, should we really wait with Eriks patch until that is done? As far as I 
understand you the patch does follow the plan of how to make the button 
configurable as well as the defaults on all platforms.

    
    

    
  
arthur - it's not necessary on other platforms, because they don't have the same desktop conventions as *nix does.

jonas - yes it's been on hold unfortunately. if i get any spare time to finish i will post it. i think that there's no reason this patch to wait for 
toolbar customization.  it should fit in the said prefs panel, for the mean time.


    
    

    
  
Cool, thanks Marlon!

Erik: I'm not really the one to review, but looking at the patches it looks 
fine. Except the two rules in themes/classic/navigator/navigator.css that are 
commented out, why is that?

Who is up for review?

    
    

    
  
The two rules are stale code, they shouldn't have been in the patch.

Anyway, I don't think the patch still applies cleanly to the current nightlies. 
Porting should be easy though. Expect a new patch by monday.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch against 2002022208 (obsolete)
        — 
          — Splinter Review
      

    


  
Patch ported to 2002022208, ready for review.

        Attachment #64189 -
        Attachment is obsolete: true

    
    

    
  
The patch has some problems in build 2002022208, it seems like bug 117184 is
creeping up again. Sometimes the location bar isn't cleared when the button is
clicked.

    
    

    
  
+        <image id="clear-button" onclick="clearLocBar();"
clearLocationBar, please.
+               tooltiptext="&clearButton.tooltip;"
get this next line to line up with the previous line
+              class="button-toolbar"/>

fix those and you can have r=timeless.

    
    

    
  
Erik: IMO this should be checked in even though there is a clearing problem.
Lets deal with that problem in bug 117184.

    
    

    
  


  
In 2002022806 the patch works fine again. No bug 117184 anymore.

        Attachment #71459 -
        Attachment is obsolete: true

    
    

    
  
I think the best way to allow Linux users to clear the URL bar is:

1. Turn on browser.urlbar.clickSelectsAll by default on all platforms.  With
clickSelectsAll, the first click selects the URL but does not change the X
primary selection, so there's no problem of accidentally overwriting the primary
selection.  This provides a large target area to click (the URL bar) and doesn't
require cluttery/ugly buttons.

2. Make sure there's still an easy way to copy the URL when you want to copy it.
 The most obvious way to do that is to make clickSelectsAll not trigger when
you're selecting text (bug 62495).  That way, selecting the URL with the mouse
the normal way (from left to right or vice versa) will still copy to the primary
selection.

3. Make sure there's still an easy way to edit the URL.  #2 takes care of the
case where you're replacing or removing text from the URL.  Bug 62491,
"double-clicking URL with clickSelectsAll should insert caret", would take care
of the case where you're adding text.

I think this is the best solution on Linux, and it doesn't muck with Linux
conventions any more than it mucks with Windows conventions.  It also provides
consistency across platforms, which isn't necessary, but is nice when you want
to set up your internet cafe to run Linux.

    
    

    
  
> the first click selects the URL but does not change the X primary selection

On a platform where selected text should always be in PRIMARY, this is an
incredibly atrocious behavior.  It completely violates user expectations in any
way it possibly can, by (1) selecting text when no selection was expected and
(2) not having selection do what it usually does.  Please see the bugs in which
unix users explain at length why clickSelectsAll should _never_ be on by default
on Unix.

    
    

    
  
Comment on attachment 71881 [details] [diff] [review]
Updated as per comments from timeless.

Please use oncommand instead of onclick (and check to make sure that still
works, of course).

    
    

    
  
Boris: the <image> element only has onclick, no oncommand. So it doesn't work.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Updated as per comments from bz (obsolete)
        — 
          — Splinter Review
      

    


  
Now using a <button> instead of an <image>.

        Attachment #71881 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 73049 [details] [diff] [review]
Updated as per comments from bz

r=bzbarsky

        Attachment #73049 -
        Flags: review+

    
  
Target Milestone: --- → mozilla1.0

    
    

    
  
*** Bug 130358 has been marked as a duplicate of this bug. ***

    
  
Keywords: mozilla1.0, 
          
            patch
Whiteboard: Needs super-review and approval of drivers

    
    

    
  
Erik, you want to mail _a_ superreviewer and _cc_ reviewers@mozilla.org.  Mail
addressed solely to reviewers@mozilla.org is not likely to get read.

I suggest alecf@netscape.com as a good person to ask for sr on this one.

    
    

    
  
This has to be hidden on Windows.  Can you attach a picture of the dialog with
the button in Classic and Modern?

    
    

    
  
Boris: thanks, I'll do that.

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

I'll attach screenshots.

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot of modern
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot of classic
        — 
      

    


  

    
    

    
  
That looks too much like Stop or close

    
    

    
  
for a more obvious icon; take the X used in classic and place it over classic's
& modern's bookmark icon. 

    
    

    
  
Of course the buttons have tooltips, so the meaning will get clear as soon as
the user hovers his pointer over the button.

An X through the bookmark-icon would come out very ugly, I think.

It's very hard to make a meaningful icon this small (at least for me it is). If
some volunteer would give it a try: go ahead. However, this X already is quite
good, IMHO. Surely its meaning isn't clear on first glance, but it'll get clear
soon enough.

    
    

    
  

      
      
      
      

        Attached image
          
        Suggestion for modern
        — 
      

    


  
Here's a suggestion for putting an x over the bookmark icon in modern. I used a
slightly downsized version of the x in the delete button in mailnews.

    
    

    
  

      
      
      
      

        Attached image
          
        Suggestion for classic
        — 
      

    


  
... and the same for classic. Using the red x from modern - the delete button
in classic doesn't have an x.

    
    

    
  
please tell me that this hasn't stranded on the fact that people can't agree on
an icon. We were sooo close :(

Oh well.. I guess I shouldn't be surprised...

    
    

    
  
The current status of the patch is basically the same as when it's got its r= :
it still applies to the current nightly (with some offsets).

Abount the icons: of course it's a matter of taste. I don't pretend to be a UI
expert but I like the current icons. I think it's very difficult for an icon
this small to have a very meaningfull picture. An X isn't that bad, IMHO, and
it'll get  clear within minutes after the user starts using mozilla.

I'll try asking for super review again.

    
    

    
  
I don't see this in any UI specs, nor have I seen any approval from any UI person
(and please don't add me to the CC of this bug, I am both against it, and will
not review until I see appropriate approval given)

    
    

    
  
Alecf: The last word in this bug from marlon bishop (which, correct me if i'm 
wrong, i'm not well-versed in the UI-world, is a UI person) is:

"jonas - yes [the UI spec has] been on hold unfortunately. if i get any spare 
time to finish i will post it. i think that there's no reason this patch to 
wait for toolbar customization.  it should fit in the said prefs panel, for the 
mean time."


    
    

    
  
sorry, change "UI spec" to "toolbar customization spec" in my previous comment

    
    

    
  
Comment on attachment 73049 [details] [diff] [review]
Updated as per comments from bz

well then! my bad.
sr=alecf

        Attachment #73049 -
        Flags: superreview+

    
    

    
  
Comment on attachment 73049 [details] [diff] [review]
Updated as per comments from bz

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

        Attachment #73049 -
        Flags: approval+

    
    

    
  
Erik, have you asked someone with CVS access to check the patch in? Today, we
probably branch.

    
  
Whiteboard: Needs super-review and approval of drivers → Needs someone to check in approved and reviewed patch

    
    

    
  
I can check this in for erik.
Whiteboard: Needs someone to check in approved and reviewed patch

    
    

    
  

      
      
      
      

        Attached patch
          
          
        cvs diff -u version (obsolete)
        — 
          — Splinter Review
      

    


  
Patch against current cvs -- attachments 64270 and 73049 unite.

        Attachment #64270 -
        Attachment is obsolete: true

        Attachment #73049 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 78180 [details] [diff] [review]
cvs diff -u version

carrying forth r=timeless,bzbarsky sr=alecf a=asa

        Attachment #78180 -
        Flags: superreview+

        Attachment #78180 -
        Flags: review+

        Attachment #78180 -
        Flags: approval+

    
    

    
  
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
Uh, why isn't this off by default? 

    
    

    
  
The urlbar is already too short - please don't steal more horizontal space.

    
    

    
  
*nix default on, all others default off.

    
    

    
  
>*nix default on, all others default off.

seeing this on windows too, and I have not enabled it manually

    
    

    
  
This bug was controversial enough to make it default off. I assumed it was. It's
enough for those who die to have it to turn it on in prefs, together with other
stuff like the Print button.

    
    

    
  
On linux, I have
user_pref("browser.toolbars.showbutton.clear", false);
but I still see the button.  Could someone please clarify how to turn this off?

Incidentally, I'd also like to turn the print button off, but I have
user_pref("browser.toolbars.showbutton.print", false);
and I see a print button too.

    
    

    
  
Why did this go into the 1.0 trunk?

    
    

    
  
Aside from not being able to turn this off: does anyone really think that having
a small "x" right next to the big "X" of the stop button (in Modern), yet having
a completely different function, is going to be clear to naive users?  That
alone is an argument for not making it the default, since it's more likely to
confuse than help the beginning user.

    
    

    
  
Erik, Christopher, this needs to be defaulted to off and the pref needs to
function. If this can't be easily fixed then please back it out until it is
fixed. Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
there is

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

turning that false should fix it?

    
    

    
  
this problem isn't restricted to the clear-urlbar-button, I get really strange 
behaviour with buttons that are not in my prefs.js. It seems to ignore the 
values in all.js and show the buttons if they were shown at last shutdown, 
could be XUL-cache maybe..

continuing to investirgate

    
    

    
  
i'm so glad people on navigator actually reviewed this abomination of UI design.
what on earth happened here that it got r and sr?!

    
    

    
  
This bug did not receive any module owner review from a Navigator module 
owners or peers.

    
    

    
  
This is a result of our wacky toolbar customization.  In order to make it go
away, you must check it, hit ok in prefs, go back to prefs, and uncheck it.  The
buttons don't ever check prefs.js to see if they need to be on, they're state is
simply stored in localstore.rdf. (I think.)

    
    

    
  
The pref works fine for me, both on a fresh profile and on my exsiting one.

Maybe it's a result of the pref being undefined when upgrading from an older
version of mozilla?

If it need to be off on all platforms by default, just back out the unix.js patch.

Maybe navigator.js needs a seperate patch to make sure all preferences are
defined when loading? I really don't think that the button shows up on windows
due to an error in this patch. It must be the sideeffect of something else.

    
    

    
  
the easy fix is to set hidden="true" on the new <toolbarbutton>, however it 
would be a good idea if we actually honored the value in the preferences 
instead. I'm trying out a patch now...

    
    

    
  
Jason's comment explains why the prefs weren't working for me.  I tried turning
the checkbox on, dismissing, then off again, as he suggested, and now the button
is hidden.

That seems like a bug -- is there one filed?  Number?  Or is that what Jonas'
patch will fix (for all the buttons, not just this one)?

    
    

    
  
yes i'm trying to fix this for all buttons, not just this one.

    
    

    
  
I had a similar problem when customizing Beonex Communicator. Maybe the state is
stored in 2 places in localstore.rdf - once for the pref checkbox and once for
the actual button. That would explain, why the pref checkbox doesn't reflect
reality.
You can fix this by creating a new profile, doing the workaround proposed above,
close Mozilla, then compare the new profile's localstore.rdf with the default
one (in profile/default). Try to sort out the related changes and moved them to
the default localstore.rdf.

    
    

    
  
OK, time to back this out.  The pref isn't sticking after a restart of the
browser.    The button looks like a mini stop button.  It shows up on windows by
default.  Please back it out, and make it work properly before it goes in again.

    
    

    
  


  
this patch makes us read the preferences and set the "hidden" attribute on all
buttons at startup.

I'm not sure if we should keep the "persist" attributes on the different
buttons. They might save a cycle or two since the buttons get the right
attribute-value earlier, OTOH it adds redundency since the preference-value is
saved in two places

        Attachment #78180 -
        Attachment is obsolete: true

    
    

    
  
What kind of hit are we going to take on new window times for this?

    
    

    
  
what happens (without the patch) is this:

We never actually read the preference data, the only time we use the 
preferences is when the browser is fully started and the user changes the 
preference.

Otherwise we rely on persist-mechanism (which stores it's values in 
localstore.rdf) and the initial value of "hidden" in the xul.

So if a user manually changes the value in either prefs.js or localstore.rdf 
(by for example removing it) the checkboxes in the preferences and the buttons 
will get out-of-sync and you have to do the "check-uncheck-trick" to get things 
working again.

    
    

    
  
i don't know how this affects startup/new-window performance and i'm outside 
the NS firewall so i can't test :(

    
    

    
  
drivers want this backed out.

caillon, please take care of it, unless someone else gets to it first :-).

Apart from the bugs, the way this was slipped in doesn't feel right. mpt isn't
even on the CC list any more. (He dropped off after the bug was reassigned to
Erik.) Plus see shaver and hyatt's comments. It looks like all the objectors
here were ultimately just ignored, except perhaps for Marlon Bishop who just
dropped the issue after claiming ignorance of Unix.

Please don't try to check this in again until you have OK from mpt, hyatt and
shaver, at least.

    
    

    
  
hyatt has made comments similar to the one he made here in the past, although 
it seems to no effect.

So, just to make this completely and utterly clear:

DO NOT MODIFY THE NAVIGATOR UI WITHOUT CONSULTING THE NAVIGATOR TEAM.

maybe having the message all-caps will help. 

    
    

    
  
Procedural issues aside, I would also like to comment on the merits of this bug.

Check out
http://www.freedesktop.org/standards/clipboards.txt
Summary: Modern Unix UIs should not --- and will not (Qt3, GTK+) --- take much
account of the PRIMARY selection. They should rely on the CLIPBOARD selection
and treat it as Windows and the Mac do. Thus there is no need for us to make the
Unix UI different to the Windows or Mac UI.

[The problems people encounter trying to use select-to-copy/middle-mouse-paste
that gave rise to this bug are *exactly* why we, along with the rest of the X
desktop world, should run away screaming from that paradigm.]

Arguments about novice users not discovering any of the shortcuts or workarounds
to this bug seem silly to me; the chance of a novice user knowing about
middle-mouse-button-paste, or understanding how it works with PRIMARY and
CLIPBOARD, is close to zero. Novice users will never need this clear button.
Advanced users can deal.

A clear button that is disabled by default on ALL platforms could be an
acceptable compromise for any disgruntled advanced users out there.

    
    

    
  
OK, let's stop beating this dead horse and become a little more productive.

My advice:  push this bug beyond Mozilla 1.0 until some kind of concensus is
reached on what to do here, and - if this bug is decided to be fixed - there's a
well-tested patch without issues.

    
    

    
  
who on the navigator team, isn't an ok from marlon enough? If naviagtor UI
requires special steps for patches then that should be noted and formalized on
http://www.mozilla.org/hacking/reviewers.html

of course it's very bad that a patch was checked in that doesn't work, however
it's not the first time it has happened and we've certainly not been so eager to
back out in all previous cases.

    
    

    
  
This feature is broken: Go to Preferences and disable this icon. Then switch
theme and restart. The icon will be back.

Back this out.

    
    

    
  
Jonas, this patch did not get technical review from a navigator module owner 
or peer.  Both the r and sr came from outside the Navigator module owners and 
peers.  One of those two needed to be an r/sr, especially since the UI was 
affected by the change.

Those people include: jag, me, hewitt, blake, ben, etc. They do not include 
timeless or alecf or marlon.  In this case the super-reviewer really should 
not have given an sr on top of a timeless r, since he should have noticed this 
patch had not been seen by any Navigator peers or module owners.


    
    

    
  
ok, point taken. Unfortuantly module-owners or peers arn't available anywhere 
on mozilla.org (appart from the list you just wrote ;-) ). However this problem 
isn't specific to the navigator module.

Anyways, i've ran Txul on attachment 78236 [details] [diff] [review] and got a perf-regression, but i 
need to do more testing to bulletproof the numbers. In the meanwhile I think we 
should set  hidden="true" persist="hidden"  on the <toolbarbutton> and back out 
unix.ps change. That way the new button will at least behave as good as the 
rest of the buttons.

Unless the navigator team want to back out the button entierly of course. 
However I don't really understand Roberts comment:

> Arguments about novice users not discovering any of the shortcuts or
> workarounds to this bug seem silly to me; the chance of a novice user
> knowing about middle-mouse-button-paste, or understanding how it works with
> PRIMARY and CLIPBOARD, is close to zero. Novice users will never need this
> clear button.

I agree with this all the way up to the last sentence. Since users won't 
discover workarounds using middle-mouse-button-paste or the primary/clipboard 
they *will* need this button. Or have to manually clear the urlbar char-by-
char. No?
Advanced users can deal.

    
    

    
  
just to clarify something, i originally made the recommendation to disable the
autocopy function by default -  that was IMO the best solution.  i finally
compromised on an idea, but never did i 'OK' an actual button, nor its actual
position on the toolbar - only what the pref panel might be.  my comment on
toolbar customization was not some sort of greenlight to check in anything
someone could come up with, i am sorry if that's how it was construed.  the
intent of my last comment was implying a compromise on a solution, however,
outside of that pref i did not agree further on what that was going to be.

Frankly this bug was way off my radar after my comment 103, and hadn't given it
further consideration since about 500 other features going on.  

nevertheless I am the guilty one, I apologize to Alec and Jonas since my
comments were carelessly ambiguous and misleading. and, for not being able to
stay current on my bug mail to catch it.

    
    

    
  
> Unless the navigator team want to back out the button entierly of course.

Jonas, by "drivers want this backed out", I meant "drivers INSIST this be backed
out, ASAP." Sorry if that wasn't clear.

    
    

    
  
> I agree with this all the way up to the last sentence. Since users won't 
> discover workarounds using middle-mouse-button-paste or the primary/clipboard 
> they *will* need this button. Or have to manually clear the urlbar char-by-
> char. No?

You misunderstood. Novice users WILL NOT USE middle-mouse-button-paste for
anything. Windows and the Mac don't have it, and it's not discoverable. If you
are using middle-mouse-button-paste, you are not a novice user, you are an
advanced user.

    
    

    
  
> Jonas, by "drivers want this backed out", I meant "drivers INSIST this be
> backed out, ASAP." Sorry if that wasn't clear.

I thought that you might have changed your mind since there now are a fix for 
it not working properly.

> > I agree with this all the way up to the last sentence. Since users won't 
> > discover workarounds using middle-mouse-button-paste or the
> > primary/clipboard they *will* need this button. Or have to manually clear
> > the urlbar char-by-char. No?
>
> You misunderstood. Novice users WILL NOT USE middle-mouse-button-paste for
> anything. Windows and the Mac don't have it, and it's not discoverable. If you
> are using middle-mouse-button-paste, you are not a novice user, you are an
> advanced user.

Exactly, and since they won't use middle-mouse-button-paste they need some way 
to clear the urlbar, i.e. the discussed button. I think i'm still 
missunderstanding you somewhere :)


    
    

    
  
The patch for this has been backed out on the trunk.

    
    

    
  
I don't know if it has something to do with this, but bringing the patches in
had a really neat effect for me, I was able again to "Install Themes" with out
Segfaulting and Deleting entries in the Adressbook, using both the Button and
the "Del" key on my keyboard. Now the Patch is backed out, I remarked it by not
seeing the handy button, I tried to "install theme" and Mozilla is segfaulting
again, Deleting of Entries in the Adressbook do also not work anymore. Is it
possible that this patch could have solve a problem it was not supposed to ? At
least the "Delete" Function in the Adressbook was a JavaScript Error and I saw
that this patch affected all.js.

But maybe it is also the change of my build options, who knows. (From Static ->
dynamic)

    
    

    
  
Thanks Christopher.

Jonas:
> Exactly, and since they won't use middle-mouse-button-paste they need some way 
> to clear the urlbar, i.e. the discussed button.

They'll select text in some other window, Copy, select the text in the Mozilla
URL bar (they'll quickly find that double-click almost always works), Paste
(replacing the selected text) and hit return. Just the way it would work on any
other platform.

    
    

    
  
I would like to see this button be turned on by default on unix: right now the
only way to delete text from the toolbar without having mozilla mess with the
clipboard is to delete its content char-by-char. 

btw - I _do_ want autocopy-to-clipboard to be turned on for unix - it's part of
the unix UI and it's (imho) quite nice this way.

Another option for clearing the URL-location entry would be to make the delete
option in the content menu to clear the menu, or add a new "clear" option.

These solutions are, imho, less preferable than a button.
Maybe the image for the button should be changed to something different. As
mentioned in comment #151, two X-buttons next to each other might be confusing
to some.

    
    

    
  
I saw this button in yesterday's build and my initial reaction was, thank god
about time.  As it's a pain to click on the url, hit the end button and
backspace char by char so I don't stomp on what's in my clipboard.  Changing the
way the clipboard works in linux I don't think is a good idea, as it will be
confusing for many unix users, myself included.

I immediately figured out that the X was to clear the url bar, one curious click
solves that problem.  But I'm a fearless linux geek, not your average user.  The
hover-over help should solve what it does for the curious, but afraid to click user.

The [x] did seem kinda of odd to see up there.  My initial thought maybe a [c]
for clear, but it's still rather non-intuitive, but maybe better than the [x]. 
  After all, I'd never know wtf the curved arrow does if I had never seen a web
brower before.  Along the same lines, I've never seen a box to clear the url on
web browser before, so of course it won't be initially intuitive, but that
doesn't mean it's not needed.

This should definitely be on by default only on unix builds, and off by default
for everything else.

Great work, this is definitely something I'd like to see ironed out and in 1.0.

    
    

    
  
>Along the same lines, I've never seen a box to clear the url on
>web browser before,

Konqueror has one; incidentally, it also is an x button to the left of the URL
bar :)

    
    

    
  
> right now the only way to delete text from the toolbar without having mozilla
> mess with the clipboard is to delete its content char-by-char.

This is not true for two reasons:
1) The clipboard that really matters, also known as the CLIPBOARD selection
(please read http://www.freedesktop.org/standards/clipboards.txt), is not
overwritten when you select text in the URL bar. [This clipboard works just like
the Mac and Windows. This is the clipboard that most people understand and  use.]
2) The clipboard you are using, also known as the PRIMARY selection, is really
for expert users only, and expert users can work around your problem in the
following ways:
-- click in the URL bar, press Ctrl-U to clear the text, and then middle click
to paste your URL from PRIMARY
-- middle click in the content area to load your URL from PRIMARY

> btw - I _do_ want autocopy-to-clipboard to be turned on for unix - it's part
> of the unix UI and it's (imho) quite nice this way.

Autocopy to PRIMARY is turned on and will stay turned on. But please read the
freestandards.org document to see why PRIMARY is not the standard clipboard and
why we should not be mangling our UI to make life better for PRIMARY users.

> Changing the way the clipboard works in linux I don't think is a good idea,
> as it will be confusing for many unix users, myself included.

We're not changing the way any clipboard stuff works. The main confusion here is
that X has multiple clipboards and most users don't know that, or don't
understand how they work, which is why we need to focus on the CLIPBOARD
selection as described in the freestandards.org document and leave the PRIMARY
selection and its Unix-only select-to-copy mechanism to expert users only.

    
    

    
  
Robert: you make it sound like you need to be some Unix-god to understand
PRIMARY. Maybe I only deal with these Unix-gods because everybody I know of uses
the primary selection and not clipboard.

Also: how do you copy to CLIPBOARD from an xterm? Most of the time I use the
clear button it's because I'm copying an URL from IRC, a README file, etc to
mozilla. The URL is always in PRIMARY. And while I do know I can paste into the
content area, I tend to forget it. I don't like clearing using ctrl-U, because
I'm lazy. Using the mouse, which I'm holding anyway is far easier.

Is this patch acceptable when the button is turned off by default on all platforms?

    
    

    
  
> Maybe I only deal with these Unix-gods because everybody I know of uses
> the primary selection and not clipboard.

It's true that xterm and some other apps just don't support CLIPBOARD. That's a
problem with those apps, and it's partly why a lot of Unix users got used to
relying on PRIMARY and ignore CLIPBOARD. Do the people you know ever wonder why
selecting text in an xterm and then choosing Paste from the Mozilla Edit menu
doesn't work? Most likely they just don't ever use the Edit menu in any
application unless they're pasting from within the same application. That's what
I've learned to do. It sucks. X has to get out of this mess and standardizing on
the CLIPBOARD selection is the only way.

There are tools that can automatically copy selections from PRIMARY to CLIPBOARD
which help.

> Is this patch acceptable when the button is turned off by default on all
> platforms?

I certainly wouldn't object.

    
    

    
  
I just read about this feature on MozillaZine. And then I read that it was
already backed out. I begging that it be put back in for 1.0 because I think I
would love the ability to have this button. Highlighting urls in the url bar on
MacOS X is kinda finiky (some times I have to click about 7 times to get it to
finally highlight all the text in the url bar just so I can delete it) so if I
could just click this one button the wipe the url bar I would love it!!!!!

    
    

    
  
Jonas, do you intend to have your patch (attachment 78236 [details] [diff] [review]) included in CVS? If
so, do you aim for moz1.0 or moz1.1?

    
    

    
  
unfortuantly it seems to cost too many cycles when opening new windows so we 
have to find some other way to solve that particular problem. So that should be 
taken to a separate bug

For now I think you should just set hidden="true" and persist="hidden" on the 
new <toolbarbutton> to at least get the new button on par with the rest of the 
buttons.

However this means that we can't have different defaults on different 
platforms, but this seems to be what most people want anyway :-)

        Attachment #78236 -
        Flags: needs-work+

    
    

    
  
small notes, there are two approaches to hidden, one is to put it in 
localstore.rdf (this is where the others are), the other would be to have 
hidden="&hideFooButton;" assuming you discover that dtd overhead for entities 
is an acceptable cost (this allows you to do per os defaults).

    
    

    
  
Paul: that's a bug that can be fixed without screwing up the UI.  Bug 97822,
"Click on URL bar selects only first half of URL (if mouse moves *at all* during
click)."

    
    

    
  
>and leave the PRIMARY selection and its Unix-only select-to-copy mechanism to
>expert users only.

Fact is, this "PRIMARY" selection is just what users get used to under unix:
there's a good chance a "novice", "naive" or "less-experienced" user will use it
as soon as they find out. Because they like it, or because someone shows it to
them: look at this... nice, huh? So PRIMARY isn't for advanced users, on the
contrary...
Now you say, current clipboard/selection bla sucks, and you start waving with
some standards.
Well, I read them, and I'm afraid I can't agree with you:
(pasting from the standard, with middle mouse-button :p)

 b) use CLIPBOARD for the Windows-style cut/copy/paste menu items;
    use PRIMARY for the currently-selected text, even if it isn't
    explicitly copied, and for middle-mouse-click (Netscape, Mozilla,
    XEmacs, some GTK+ apps)

 The current consensus is that interpretation b) is correct. Qt 3 and
 GNU Emacs 21 will use interpretation b), changing the behavior of
 previous versions.

-> use PRIMARY for the currently-selected text, even if it isn't explicitly
copied <-

So - user selects text -> app copies it to PRIMARY

This is exactly what happens when I select text in the location bar that I want
to delete. I'd rather not do that because I want to keep PRIMARY 'clean'.

You state that users shouldn't use the PRIMARY for copy+paste operations. Why
not? As far as I can see, that's _not_ what's in that doc:
"X has a thing called "selections" which are just clipboards"
So, PRIMARY is a clipboard. I can use it for copy-paste-operations. A majority
of the unix users uses PRIMARY for this.

So to prevent me from having to mess up PRIMARY and to save time too, give
unix-users a clear button... 
Please?

    
    

    
  
You quote selectively. The text you quoted simply says that what we currently do
is what everyone should do and that it's fine for PRIMARY to still work. Sure.

The important text is here:
> The correct behavior can be summarized as follows: CLIPBOARD works
> just like the clipboard on Mac or Windows; it only changes on explicit
> cut/copy. PRIMARY is an "easter egg" for expert users, regular users
> can just ignore it; it's normally pastable only via
> middle-mouse-click.

Since regular users can just ignore it, and other users have workarounds that
are just as good, I don't think it's right to steal screen real estate to
support it.

    
    

    
  
The 'clear' button does improve mozilla's usability under unix. We have 12 votes
(including me), the other major browser Konqueror has it, so Robert O'Callahan
what is your point? If you dont like a clear button please dont use it or
disable it.

Mozilla is not in place to change how copying under Unix works at the moment.
Most user I know use Primary all the time. You are talking about novice users,
how many percent of the userbase are beginners? Please backup your opinion with
some usability studies.

So please enable the clear button by default. (BTW It is much smaller than the
search or print button which I never use)

    
    

    
  
If it's not Mozilla's place to help make Linux more appealing to normal users,
whose place is it?

    
    

    
  
We can't design a UI by adding every button which gets 12 votes.

    
    

    
  
What about designing a UI based on 1 vote as in bug#10096, bug#47387, and
bug#72632. Or maybe 3 votes as in bug#33420 or 6 votes for bug#32087.

    
    

    
  
My bad.
 s/bug#72632/bug#72623/

    
    

    
  
See comments #43, #75, #96, #105, #189 why this is nice to have on other
platforms too. Lot's of novice users on win/mac delete the URL bar manually
character by character (watch your daddy, grandma, non-geek-colleague). I don't
mind if it's turned off by default, but I would like to be able to turn it on
for the _novice_ users I set up computers.

PRIMARY selection is actually the main reason why I've switched to linux, it
saves so much time if you have to do lot's of copy/paste stuff. And it's the
thing I've learnt to use long before I was an experienced user. PRIMARY
selection rocks!

    
    

    
  
Hmm. Just to throw in my two cents....

I recently filed a bug (bug 137273 - which should probably be marked duplicate
of this one) because this feature was so incredibly useful to me. The reason is
simply that I did not know about the double clicking (I discovered that one this
thread). The problem is that double clicking is not intuitive, since normally
double clicking will select 1 (one) word, not one line, or one random group of
text. So I always, selected the entire text (by dragging) and then pressed the
delete, backspace or paste keys, depending on what I wanted.

I vote for this bug since I believe that it makes the UI clearer and more intuitive.

Note, I do use Linux and Windows builds of Mozilla, and I like the fact
that the interface is the same, and personally I would enable this everywhere.
By default it could be disabled, I don't mind, but I would enable it for sure!

    
    

    
  
I'll try to deliver a new patch on monday.

- default off on _all_ platforms
- default off after upgrading from an older version of mozilla
Status: REOPENED → ASSIGNED

    
    

    
  
I have a quit long home page URL (a bugzilla query on a local bug database).

If I want to enter anything in the URLbar (like my favourite bookmark keyword
"bonsai"), I always have to select the whole URL (e.g. by double-click) before I
can enter anything. It would be _really_ nice if I could activate that button
and simple click it for that purpose...

Perhaps I'll need it a small bit less often now that you reminded me of
middle-button paste page loading, I never actually used it...

    
    

    
  

      
      
      
      

        Attached patch
          
          
        New try
        — 
          — Splinter Review
      

    


  
This is the button with hidden="true" persist="hidden". On a new profile the
button is hidden, the user can enable it from preferences.

    
    

    
  


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

Patch is not in CVS format.

    
    

    
  
> It's true that xterm and some other apps just don't support CLIPBOARD.

xterm supports CLIPBOARD. It's just not the default for the pointer buttons.
Bind some key sequences to insert-selection(CLIPBOARD) and select-end(CLIPBOARD)
actions and there you go.

    
    

    
  
*** Bug 137788 has been marked as a duplicate of this bug. ***

    
    

    
  
Notice that Sun keyboards have the L-Keys, including
3 labled "Copy", "Paste", and "Cut" for accessing the CLIPBOARD.
The Problem is PC keyboards don't have them. So you end
up with Unix (X11) symantics with out the keys to utilize them.

The windowmanagers/Desktop Environment shold have defaults
for PC keyboards to gain this functionality.


    
    

    
  

      
      
      
      

        Attached image
          
        just an example
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        screendump
        — 
      

    


  
My kids really like this button. I can't expect them to remember all the
mozilla shortcuts. So for all mom-users, here it is :-)

    
    

    
  
Right, 1.0 is out, let's work on this patch again :-) I simply changed the
target milestone and keywords; expect some real work soon.
Keywords: mozilla1.0 → mozilla1.1
Target Milestone: mozilla1.0 → mozilla1.1alpha

    
    

    
  
Is there a problem with your patch from comment #205? I have applied it to all
releases since you posted it, and it did not give me any problems (besides not
having a good icon for all themes).

    
    

    
  
Checkout the new Multizilla at mozdev.org. Next to the functionality it used to
provide, it adds a clear button. Just use that icon if licensing permits it.

    
    

    
  
You can use http://diggler.mozdev.org/ until this bug is fixed.

    
    

    
  
See also bug 76010, paste onto selected text in location bar should overwrite
instead of insert.

    
  
Component: User Interface Design → URL Bar

    
  
Summary: [RFE] button to Clear the URL field → button to Clear the URL field

    
    

    
  
What's the status of this? Comment #212 (from 2002-06-06) said "expect some real
work soon", but than nothing happened...

    
    

    
  
I will also find this clear button very usefull for Unix.
 I don't understand why some of you don't want a button for this function. I
have no idea about design of UIs, but I thing that if the button is useful, it
should exist this button.
  Clearing the location bar is a task very very very frequently performed.
Can you do a survey about how many people uses the little "copy source" button
that it's placed at the left of the "http"? And another survey about the print
button...
I think that we clear the location bar more frequently than we print something.

    
    

    
  
*** Bug 186380 has been marked as a duplicate of this bug. ***

    
    

    
  
> What's the status of this? Comment #212 (from 2002-06-06) said "expect some real
> work soon", but than nothing happened...

I don't think it's worth the bother. The mozilla organisation doesn't seem to
want it, so there's no point for me to continue working on this patch. They
don't seem to care about Unix :-/

If someone wants to take over this bug: you can have it.

    
    

    
  
*** Bug 193066 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 199765 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 229679 has been marked as a duplicate of this bug. ***

    
    

    
  
Also asking for a solution, copying-and-pasting URL's with the classic Unix
mouse method is a real pain in the a** with mozilla compared to Konqueror (I'm
just considering Mozilla instead of Konqueror):
* In Konqi, I just delete the URL field with a click on the delete button and
paste the URL with the middle button.
* In Moz, I first left-click into the URL field to give it focus, then perform
some keyboard operations which need *both* hands (because shift or control is
involved) to empty it, and then paste with the middle button.


    
    

    
  
or you press the middle mouse button over the content area...

    
    

    
  
*** Bug 324622 has been marked as a duplicate of this bug. ***

    
    

    
  
There is an Extention that adds this Feature:

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

HTH

    
    

    
  
Another way to handle this problem is to add the 'new tab' button to the toolbar next to the URL field.  Then just click 'new tab' and middle-click in the URL field to paste.  But I agree an optional clear URL button is useful, and no more intrusive than the other optional buttons.
Product: Core → SeaMonkey
QA Contact: zach → location-bar

    
    

    
  
I'm closing this bug because the feature can now be easily implemented using an extension. If anybody else would like to take it, please reopen it and assign it to yourself.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → WONTFIX

    
    

    
  
(In reply to Erik Hensema from comment #229)
> I'm closing this bug because the feature can now be easily implemented using
> an extension. If anybody else would like to take it, please reopen it and
> assign it to yourself.

Erik, I know that this is a very old bug… but which extension should be used to modify this field? I would have through that we could hook into bug/field-end_field_column, however URL isn't a "field", and so there isn't a logical place to put the code to fixup the URL entry.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: