88093 - Add a "Clear" button to the Linux "Open Web Location..." dialog.

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Michael Cramer]

As a minor UI enhancement, I suggest adding a "Clear" button to the "Open Web
Location..." dialog. As it stands now, I can not use the dialog to using just
the mouse. I have to hit "delete" when the dialog opens to clear any existing
address. You can use the  dialog with just keyboard shortcuts and keystrokes, so
it seems only fair that you could use it with just mouse clicks instead.

PS: I'm running a self-compiled build of MOZILLA_0_9_2_BRANCH under Linux.
Although I imagine the interface is the same on other platforms as well.

Comment 1

[Chad Austin]

Workaround:  Double-click in text box, right-click, click delete.
UI people?

Comment 2

[R.K.Aa.]

*** This bug has been marked as a duplicate of 24651 ***

Comment 3

[Michael Cramer]

Sorry to be a pain, but 24651 isn't the same issue. That bug concerns the
location box on the main browser window. I'm interested in the "Open Web
Location..." dialog. It's a similar question, different part of the UI.

I'll attach a patch that makes the change I'm interested in (although my xul
skills are minimal, so I couldn't figure out how to position it between the
"Open" and "Cancel" buttons to make it match Communicator 4.7). 

Comment 4

[Michael Cramer]

Attachment: patch to add a "Clear" button to the "Open Web Location" dialog.

Comment 5

[Asa Dotzler [:asa]]

-> XPApps GUI Features. Blake. Confirmed. keywords and stuff.

Comment 6

[Blake Ross]

This is not getting added on Windows, at the very least.

Comment 7

[Michael Cramer]

That's fine...it seems to only be an issue under X.

Comment 8

[timeless]

ok, that means you'll need to try to make an overlay for this.  If that doesn't 
work, we might accept a button which is only shown for x11.
fwiw, the patch you made had bad indentation... good luck, and if you need help 
getting this committed, contact me on irc (or someone else, we're usually 
available and friendly). information on overlays can be found online or on irc 
(try irc.mozilla.org #mozillazine). good luck

Comment 9

[sairuh (rarely reading bugmail)]

this also existed in comm4.x on unix.

Comment 10

[Michael Cramer]

Attachment: Patch and new files to add "Clear" button only under Unix.

Comment 11

[Michael Cramer]

Just posted the patch. It contains three new files which in turn contain
platform-specific javascript functions to enable or disable the "Clear" button.
Only the "unix" version enables it, the "mac" and "win" versions are stubs which
just return 0.

It also contains a patch file which makes the appropriate changes to some
existing files.

Comment 12

[Michael Cramer]

Attachment: And here's a new version of the patch to fix an indent oops.

Comment 13

[timeless]

archive appears to be .tar.gz ...
for js, you would usually use |return true| and |return false|

but you seem to be passing around an object -- i think
  return clear;
i would expect this to be |return dialog.clear;| but i'm probably wrong.
assuming you're returning an object here, i would expect you to return null 
instead of 0 for win/mac. -- i could be wrong.

you can't do  |dialog.clear.label = "Clear";|
because that's not localizable.  since you have a properties file you'll need 
to use the properties functions... 
I think this should work, test first ...
  var bundle = 
srGetStrBundle("chrome://communicator/locale/openLocation.properties");
dialog.clear.label=bundle.GetStringFromName("clearButtonLabel");

Comment 14

[Michael Cramer]

activateClearButton() is reaturning "clear" under Unix, which is the name of the
function which is actually called when that button is pressed. Javascript seems
to pass a reference to a function if you leave off the () after the name,
instead of actually calling the function immediately. doSetOKCancel() seems to
take function references or 0 in determining whether to show the buttons or not.
That's why the win and mac versions return 0 and the unix version returns the
"clear" reference.

As for the "Clear" being hard coded: that was just a slip-up. I was moving my
changes around quite a bit and must've forgotten to replace the "Clear" with the
appropriate reference to the properties file. That's fixed as well.
Tar/gzip with new files and patch follows...

Comment 15

[Michael Cramer]

Attachment: Patch adds "Clear" button to open location dialog.

Comment 16

[timeless]

ok, thanks for clarifying, it looks ok to me

Comment 17

[timeless]

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

Comment 18

[Matthew T (active 1999-2002)]

Instead of adding a `Clear' button, I think we should just follow 4.x behavior
and make the field in the `Open Web Location' dialog be empty whenever you open
it. There's no point in defaulting that field to the current URL, when the very
fact that you opened the dialog indicates that you're not at all interested in
the current URL or an edited variant thereof. (If you were, you would have
clicked in the address field or hit Control+L).

Comment 19

[Blake Ross]

[It's actually not the current url, it's the last url you opened from that
dialog. Whether that's useful, you decide]

Comment 20

[Matthew T (active 1999-2002)]

Ok:

No, it's not useful. :-)

Please just make the field blank. While you're at it, remove the hack workaround
for bug 28583 which Blake put in, i.e. the code which selects the contents of
the field when the dialog is opened.

Comment 21

[Blake Ross]

Umm...I didn't realize you speaked for the whole world. It was added on request,
so yes, it's useful for at least one person.

Comment 22

[Matthew T (active 1999-2002)]

You didn't ask me to speak for the whole world, you asked me to decide. :-]

I do think the Open Location dialog should have a bookmarks menu and a history 
menu in it, just like (on Mac OS, at any rate) the Open File dialog does. 
However, I do not think the first item in that history menu is important enough 
to pre-fill the field with (even when the history menu hasn't been implemented 
yet), when you're almost certainly going to be wanting something completely 
different, and when pre-filling makes life very difficult for *n*x users.

Comment 23

[Jesse Ruderman]

Another possible solution: automatically select the default contents of the
"open web location" dialog when it opens, and make it so that middle-clicking on
the selection replaces it with the X selection rather than inserting the
contents of the X selection.  (Bug 76010.)

I think mpt's solution is reasonable, though.  The Open File dialog doesn't come
with the last-opened file selected, so why should the Open Web Location have the
last-opened URL filled in?

Blake: was the file-in-the-last-value behavior requested before or after
autocomplete was added to the Open Web Location dialog?

Comment 24

[Michael Cramer]

> make it so that middle-clicking on the selection 
> replaces it with the X selection rather than 
> inserting the contents of the X selection.

Nothing else (in X at least) works this way, so making
this one dialog do it would be confusing. An empty
text field would be better.

Comment 25

[R.K.Aa.]

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

Comment 26

[Asa Dotzler [:asa]]

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

Comment 27

[Michael Cramer]

Attachment: Patch to add a "Clear" button to openLocation on all platforms.

Comment 28

[Michael Cramer]

Attachment: Patch to always leave the input field empty

Comment 29

[Michael Cramer]

I just attached two different patches. One adds the "Clear" button to all
platforms. Obviously, this is not going to be applied because there is no need
for it on non-Unix platforms. If someone could give me some pointers, I'll
gladly make it platform-specific. I imagine it's an overlay thing, but I can't
figure it out except to create dummy functions on all platforms (as I did in my
patch of 7/2/01).

The second patch just removes the old URL from the input field altogether.

Comment 30

[Aaron Sloman]

I am voting for this bug because I find having to switch between mouse and
keyboard (to delete old URL) when pasting in a location very irritating and also
error-prone, because I get the sequence wrong and paste on top of the old URL.

I don't much care whether the open url dialog starts empty or whether a "clear"
button is provided to fix the problem, but I'd slightly prefer a clear button.

Occasionally having the previous URL by default is useful if I want to get
a related URL by editing it, but the history mechanism seems to provide that
functionality in any case, if I have understood it properly.

I currently experience this bug mainly as a user of netscape 6.2.1 on linux+PC
but I have seen it on mozilla on solaris+sparc.

Aaron
[e-mail] 

Comment 31

[jag (Peter Annema)]

I'd prefer the location field to be empty instead of adding this button.

sr=jag on that last patch.

Comment 32

[Matthew Miller]

Blank actually does seem good -- how often do you want to open the exact same
site twice in a row?

Comment 33

[Aaron Sloman]

 Matthew Miller writes:
"Blank actually does seem good -- how often do you want to open the exact same
site twice in a row?"

Rarely. But I quite often want to open an edited version of the previous site's
URL, e.g. when a url returns non-existent page, I can sometimes get the
information I want (about  a person who has moved, for instance, or a new
location for a department's publications) by going to a higher level URL.

However I agree that the majority of times I just want the field cleared, which
is why I used the clear button so often in netscape 4.7 and sorely missed it in 6.2.

Comment 34

[sairuh (rarely reading bugmail)]

moving open bugs pertaining to the Open Web Location dialog to [e-mail]
as qa contact.

to find all bugspam pertaining to this, set your search string to
"GottaGetThisHenOut!"

Comment 35

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 36

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 37

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 38

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 39

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 40

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 41

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 43

[Aaron Sloman]

(In reply to comment #42)
> *** This bug has been confirmed by popular vote. ***

I have no idea why bugzilla sent out this message. I removed my vote for another bug simply because I was getting too many bugzilla messages, and somehow that prompted a message about this bug to be broadcast as coming from me.

Maybe there's a bug in bugzilla?

Anyhow, apologies to anyone inconvenienced.

Comment 44

[Philip Chee]

On trunk, the input box comes up blank which should be enough for most people. Also see Comment 31