From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14masq i686; en-US; m15) BuildID: 2000041811 After moving a bookmark from one location to another within the either the sidebar or the organize bookmark page. It doesn't appear within the new folder that you have dropped it within unless you collapse the folder and then expand it again. Reproducible: Always Steps to Reproduce: 1.Open up the bookmarks window 2.drag a bookmark into a folder. Actual Results: the bookmark apparently disappears. Expected Results: The bookmark appears within the folder.

Confirming on m15 2000041805 with linux i686.

Is this a tree widget bug? I swore up and down it was a dupe but I can't find it anywhere. Basically folders aren't updating their contents (their view?) soon enough, instead they have to be forced to do so by collapsing/expanding them or otherwise forcing them to redraw. This is XP also.

Using the 2000-05-02-15-M16 nightly binary, this works for me for dragging bookmark items into an open folder, but not for dragging a folder into an open folder.

Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.

grrrr. I can't find a dupe. If there is a dupe, hyatt should know because I think this is a tree bug. reproduces jsut like sean say with the 2000051210 builds

Move to M19 target milestone.

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] for fix deadline.

Added "rjc" to status whiteboard ...

Cleaning up status whiteboard marking beta2 minus (we're past 6/15). This bug sounds like it provides the *appearance* of datasloss (loss of a moved bookmark intil you open/close). We need to clean this up, or pull the drag/drop features for bookmarks. Nominating for beta3

This is a server side bug. Changing priority back to P1: must be fixed for PR2.

Removed nsbeta3, and changed status in whiteboard to [nsbeta2+]

rosilene, I don't understand your comment that this is a server side bug...I don't even see how that's possible. This has nothing to do with connections or anything. also confused how this got marked nsbeta2+...are you on the PDT? Jim just marked this nsbeta2- a couple days ago, and I agree that it should remain -. removing nsbeta2+ designation for reconsideration

Putting on [nsbeta2-] radar. Not critical to beta2.

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

This bug does not appear to be search-related and should not be assigned to me.

rosilene assigned it to jlinley, I don't know why though (bugzilla corruption?) anyways, slamm's on sabbatical, right? rjc, any idea here?

Nav triage team: [nsbeta3+]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

Looks like someone fixed it. It takes a while, but it works on Windows and Linux.

REOPENED. Sean's comments from 05-03 tell the tale. Moving a bookmark _folder_ into another folder causes it to disappear until you refresh the folder (collapse and expand) Tested with the 2000082108 build on Win98

PDT downgrading to P3 with [PDTP3] in status whiteboard

Removing "nsbeta3+" and reassigning to rjc. Robert, is there anyway in Hell that you can fix this? Slamm is gone and nobody else on my team has a clue about this one.

nsbeta3- in keeping with PDT rating.

you drop or paste a folder into a folder and *poof* your folder is gone. Okay, okay it only looks like it's gone but it's still disconcerting. Clearing status whiteboard for reconsideration

Sorry, Claudius, clearing the status whiteboard brings it to the attention of the PDT only to the extent that they harass me about untriaged bugs. You have to appeal this *to* the pdt, either in person (4pm Star Trek daily) or via mailto:pdt@netscape.com

hmmm, no chance for beta now. nominating for rtm. if someone minuses this bug I will show up in person at their location, forthwith.

I traced this through the XUL template builder: we *are* calling ContentInserted(), and it appears that we're passing in valid info. I need hyatt or bryner or evaughan to help me debug in the tree code. evaughan: I hear you have a whole lotta tree love? Can I try your patches? Also, the trick to reproducing the bug appears to be to drag *anything* (a folder, bookmark, whatever) from the outermost ply into an open, nested folder. Dragging between two open folders seems to work.

Robert, Chris: the investigation so far makes this sound like a tough problem to solve with a potentially risky fix. Plus this is NOT a P1 bug (annoying to be sure, but there's a workaround). Is there a quick safe fix for RTM? Is this really the most important thing you have to work on at the moment? [rtm-] for now. This should be nominated for one of the Mozilla milestones I guess.

This is a DUP of a bug David/Eric are working on, I believe... David?

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

at the very least 48265 is a dupe of this but hyatt/eric weren't working on that particular bug, AFAIK. tweaking this summary as it seems 48625 was easier to find for dupes

targetting moz1.0

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

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

Netscape Nav Triage Team: hyatt - does this work?

I think this was fixed in bug 56349. (That bug is still open for a edge case variation, dealing with visible rows of the tree, but the bug appears fixed for the conditions described in this bug). *** This bug has been marked as a duplicate of 56349 ***

grrr, VERIFIED Dupe of the newer bug.