Closed Bug 11412 Opened 25 years ago Closed 23 years ago

implement 'remove from history' (can't delete items from window)

Categories

(Core Graveyard :: History: Global, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: waterson, Assigned: dead)

References

Details

(Keywords: helpwanted, regression, Whiteboard: suntrak-n6)

Attachments

(2 files)

Cannot currently remove history entries. Implement this feature!
Status: NEW → ASSIGNED
Target Milestone: M11
Blocks: 11411
Target Milestone: M11 → M15
Sliding non-critical tasks
QA Contact: leger → claudius
Updating QA contact
Component: Browser-General → History
Target Milestone: M15 → M20
-> mfuture
Keywords: helpwanted
Target Milestone: M20 → Future
*** Bug 47550 has been marked as a duplicate of this bug. ***
unless i'm confusing this with another feature, this was in 4.x (at least in
win32 --doesn't seem to work/be active on Mac or linux 4.7x).

adding relnote kw/notes, since the menu item is present in mozilla/6.0, but is
non-functional.
Keywords: 4xp, relnoteRTM
Summary: [rfe] implement 'remove from history' → implement 'remove from history'
Whiteboard: relnote-user
waterson just did clear history.  deleting single items shouldn't be much more 
difficult, says the guy who has no clue...
Keywords: ns601
Keywords: ns601mozilla0.9
*** Bug 58801 has been marked as a duplicate of this bug. ***
*** Bug 58801 has been marked as a duplicate of this bug. ***
*** Bug 59237 has been marked as a duplicate of this bug. ***
updating summary to catch more dups
Summary: implement 'remove from history' → implement 'remove from history' (can't delete items from window)
note: it's bad that the menu item "delete" is currently available to users but
selecting it doesn't do anything.
Adding sun tracking string.
Whiteboard: relnote-user → relnote-user suntrak-n6
Adding to "Changed Features" section of "Upgrading to Netscape 6" (Migration 
Guide)
probably stating the obvious, but trying to delete entries in history window
only spawns this in console:

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIRDFContainer.Init]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location:
"JS frame :: chrome://communicator/content/bookmarks/bookmarks.js :: doDelete ::
line 504"  data: no]
************************************************************
An error occurred executing the cmd_delete command

(on linux, build 2000113006)
I presume you all are talking about the Tasks->Tools->History window. If so,
this will go to Alec Flett.
Assignee: waterson → alecf
Status: ASSIGNED → NEW
coolness, I like this idea
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Target Milestone: mozilla0.9 → mozilla1.0
ok, I have a fix for this, attaching a patch shortly.

the patch is pretty mammoth because it refactors a lot of code... the actual
feature was fairly trivial (but the nice thing is that nsGlobalHistory is
actually smaller after the patch is applied, even with this feature implemented)
looking to radha for review, waterson for super review
Sexy. r=waterson
nav triage team: nsbeta1 p3
Keywords: nsbeta1
fix is in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reopening..
This is not fixed on Linux 20010123, Win98 20010123 (thanks sumner2 on #mozillazine)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
this works fine for me on linux, 2001012408 build.. I can delete or cut.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
*** Bug 66546 has been marked as a duplicate of this bug. ***
*** Bug 66546 has been marked as a duplicate of this bug. ***
reopening bug; I can't deleting items from my history consistently (Mac mozilla 
debug build from today after brendan's backout).

I tried the menu as well as the delete (backspace) key.  I think I did manage to 
delete one item after resorting the contents but I couldn't delete anything after 
that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Component: History: Session → History: Global
I think this is just some nsTreeController oddness.
Assignee: alecf → pchen
Status: ASSIGNED → NEW
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla1.0 → mozilla0.9
Marking nsbeta1+, reassinging to pchen to take a look on mac
Using 2001031008 on Win98se

I can delete history items with either <del> or edit->delete.

However, for the change to be reflected, you have to force a refresh of the
history item's folder (either closing/opening it or closing history and reopening).

I got a bit of unreproducible behavior where a folder which I deleted an item
from would not open up again.  Closing and reopening the history window did not
clear it up.
Try right-clicking on an history item. Instead of the expected context sensitive
popup menu only a little empty square appears. (Moz 0.8.1, Linux).
Moving to mozilla0.9.1, though I think this is a dup of some history bug alecf has.
Target Milestone: mozilla0.9 → mozilla0.9.1
This used to work; cc'ing alec so he's informed.
this broke when we switched to hierarchical history.. basically we need to make
sure to unassert the deleted URL from a few of the 'well-known' find URIs.. look
at NotifyFindAssertions (or whatever it's called) - probably need to do the
reverse of that.

I should add that the delete-by-domain and delete-by-hostname feature is also
_sort_of_ broken in the same way this one is... but the solution to that is to
simply remove the hostname from a few of the toplevel find uris... someone want
to file a seperate bug?
I thought it broke with hierarchical history also, and was going to say that, 
but that landed after ~1/23, no? *shrug*
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 76947 has been marked as a duplicate of this bug. ***
this bug was fixed(delete was implemented) a while ago and then regressed. While in its regressed
state bug 82571 was filed. Technically this bug was fixed and we're just looking at a new regression.

I can't very well mark it fixed and it's certainly not a dupe of the other so I'm just going reassign
it to Blake (the correct owner of 82571) and make the new one a dupe.

The issue of the deleted item not displaying as such(proving that delete was implemented btw)
until the twisty of its container was collapsed and expanded again became bug 82158.
Assignee: pchen → blakeross
*** Bug 82571 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.2 → mozilla0.9.3
This is fixed, right Alec?
yep.. taking back from blake
Assignee: blake → alecf
Status: ASSIGNED → NEW
re-marking fixed
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
verify on my mac debug build from today; HURRAY!!!!!!
Target Milestone: mozilla0.9.3 → mozilla0.9.2
Am i missing something? With a 2001062108 Mac build and a 2001062111 Linux build I can't
delete any single history item from anywhere in any fashion. Global window+Sidebar from the menu
and from the keyboard no results whatsoever. I did see any errors to the console either.
REOPENING.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
augh! this worked!
This is also failing for me on windows 2001-06-21-04

I really want to know WTF is going on.
augh! this worked!
This is also failing for me on windows 2001-06-21-04

I really want to know WTF is going on.
I'm getting an error message on the console "An error occured executing the
cmd_delete command"
Blocks: 81258
Keywords: nsBranch
strangely, this seems to work in my tip build.. *sigh*
ok, more updates, with today's Linux builds:

mozilla tip nightly: works
netscape tip nightly: broken
mozilla branch nightly: works
netscape branch nightly: broken

so it appears to be something specific to the netscape builds.. MAYBE its a
packaging issue? I don't know.
Yeah.  Works in my homegrown builds.  When I try to delete in a comm nightly, I 
get this js error:

Error: RDF has no properties
Source File: chrome://global/content/nsTreeController.js
ah HA! did you get a source line with that?
Oops, yeah.  324.
Attached patch hack fixSplinter Review
ok, "RDF" is SUPPOSED to be a global variable in this file, and for some reason
is not... I've attached a hacky fix for the 0.9.2 branch. Can I get a
review/super review?
Status: REOPENED → ASSIGNED
Whiteboard: relnote-user suntrak-n6 → fix in hand, need r=, sr=, a=, relnote-user suntrak-n6
r=brade
Whiteboard: fix in hand, need r=, sr=, a=, relnote-user suntrak-n6 → fix in hand, need sr=, a=, relnote-user suntrak-n6
Hmm.  Scary.  Cc'ing Brendan.  Copy is in the same boat (as is paste, but 
history is readonly), is it running into this problem too?

sr=blake
removing relnote-user because I fully expect to fix this
Whiteboard: fix in hand, need sr=, a=, relnote-user suntrak-n6 → fix in hand, need a=, suntrak-n6
pushing out. 0.9.2 is done. (querying for this string will get you the list of
the 0.9.2 bugs I moved to 0.9.3)
Target Milestone: mozilla0.9.2 → mozilla0.9.3
ok, fix checked into the branch. removing extraneous keywords.
leaving bug open so we can figure out what is really going on.
Keywords: nsbeta1+, nsBranch
Whiteboard: fix in hand, need a=, suntrak-n6 → suntrak-n6
nav triage: we can postpone this work now, -> m1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
Does copy work?

Copy is in the same situation as delete. I don't understand why it would.
*** Bug 89927 has been marked as a duplicate of this bug. ***
doh doh doh doh doh

I wish someone had read my 7/2 comment.  Copying is indeed broken on the branch.
nav traige team:

Would like to fix this for 0.9.4. Reassigning to blaker@netscape.com
Assignee: alecf → blaker
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → mozilla0.9.4
This is fixed with outliner history.

Brendan, you may want to look into why the previous js wasn't working?
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I can't say why RDF was not found in nsSessionHistory_delete's scope parent:
perhaps the window in which the variable was a property had its scope cleared by
DOM code?

Someone get this in a debugger and drag me ove from waterson/cathleen land --
I'm in tomorrow during the day.

/be
VERIFIED Fixed with 20010907 builds. ther are still some issues with updating
the view after delete in the "old skool" view but that's for another bug...
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: