81065 - Delete Host vs. Delete Domain

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[lchiang]

In the Edit pull-down menu in the History Dialog... 

In all instances where a particular page (within a domain) is NOT selected, the 
menu shows "Delete Host" and "Delete Domain". What is the difference between 
these two, and for the sake of good user interface can we get rid of "Delete 
Host"? It seems that only "Delete Domain" is needed here, but I could be wrong. 

Also, see bug 4986, which talks about how that "Delete Domain" function doesn't 
seem to work, even when a domain is selected.



------- Bug moved to this database by [e-mail] 2001-05-15 15:53 -------

This bug previously known as bug 4987 at http://bugscape.netscape.com/
http://bugscape.netscape.com/show_bug.cgi?id=4987
Originally filed under the Browser product and Browser-General component.

Comment 1

[lchiang]

.

Comment 2

[Todd Pringle]

Alec,

I tend to agree here - the distinction isn't an easy one to understand for end
users.  Also, do we have a separate bug on this not working - I haven't seen
them during any of our triage sessions, which worries me.  I also believe that
Delete Domain should be enabled when a user has a domain selected, not just when
they have a page within a particular domain selected - is that a separate bug
too?  Let me know if so and I'll file.

Comment 3

[Jeremy Loeb (gone)]

The top-level problem is noted in 
http://bugzilla.mozilla.org/show_bug.cgi?id=81061

Comment 4

[Alec Flett]

you can delete them, they just don't update in the ui until you collapse and
reexpand the twisty...(which is another bug that I have... somewhere!)

Comment 5

[Alec Flett]

oh, and to clarify:

Domain = the entire domain, such as "porn.com"
Hostname = just the paricular site, such as "images.porn.com"

These menu items should probably be hidden instead of disabled, when the user is
not selecting anything

when the user is selecting something, we should probably come up with better
wording.

Comment 6

[Todd Pringle]

Alec, can you make sure that other bug is nominated?  I think that's one we
should try to get in for rtm.

Comment 7

[Alec Flett]

I couldn't find the other bug, so I filed a new one
it's bug 81258

Comment 8

[Alec Flett]

argh.. take two at reassigning history bugs to new owner

Comment 9

[Peter Trudelle]

Hardly any users will know what either 'host' or 'domain' means.  However, these
menu items currently give further cues. If I select a page from
tinderbox.mozilla.org, they say:

Delete all from tinderbox.mozilla.org
Delete entire domain mozilla.org

Getting rid of 'host' was probably good; I'm not sure why we left 'domain'. 
Perhaps it would be enough to change it to "Delete all from mozilla.org".  

Stepping back a bit, do we really need to supply both?  What is the usage case
scenario that requires us to provide an easy way to delete history items from
one server within a domain?

Comment 10

[Todd Pringle]

I do not believe we should make this distinction - IE to my knowledge does not
in their history feature - and frankly as Peter says most users will simply be
confused.  I believe they are typically making their deletion decision based on
domain (without knowing it is called domain) and this is how their history
should be presented.  

Comment 11

[Steve Simms]

See Bug 155928 regarding renaming "delete entire domain xxx" to "delete all from
domain xxx", which should make things easier to understand.

Comment 12

[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 13

[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 14

[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 15

[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 16

[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 17

[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 18

[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 19

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 20

[Karsten Düsterloh]

We now use "Website" instead of "Host".