Closed Bug 36873 Opened 24 years ago Closed 24 years ago

Bookmark/Folder moved into open folder does not appear until collapse+expand

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 56349
Milestone:
mozilla1.0

People

(Reporter: ben, Assigned: hyatt)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta2-][nsbeta3-][rtm-]) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
OS: Linux → All
Hardware: PC → All
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.
Keywords: nsbeta2
Whiteboard: [FEATURE]
Target Milestone: --- → M17
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
Whiteboard: [FEATURE] → [nsbeta2+][6/01][FEATURE]
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.
Target Milestone: M17 → M19
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.
Whiteboard: [nsbeta2+][6/01][FEATURE] → [nsbeta2+][Will be minus on 6/15][FEATURE]
Added "rjc" to status whiteboard ...
Whiteboard: [nsbeta2+][Will be minus on 6/15][FEATURE] → [nsbeta2+][Will be minus on 6/15][FEATURE][rjc]
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
Keywords: nsbeta3
Whiteboard: [nsbeta2+][Will be minus on 6/15][FEATURE][rjc] → [nsbeta2-][FEATURE][rjc]
This is a server side bug. Changing priority back to P1: must be fixed for PR2.
Assignee: slamm → jlinley
Priority: P3 → P1
Removed nsbeta3, and changed status in whiteboard to [nsbeta2+]
Keywords: nsbeta3
Whiteboard: [nsbeta2-][FEATURE][rjc] → [nsbeta2+][FEATURE][rjc]
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
Whiteboard: [nsbeta2+][FEATURE][rjc] → [FEATURE][rjc]
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [FEATURE][rjc] → [nsbeta2-][FEATURE][rjc]
*** 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.
Assignee: jlinley → slamm
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+]
Whiteboard: [nsbeta2-][FEATURE][rjc] → [nsbeta2-][FEATURE][rjc][nsbeta3+]
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3
Looks like someone fixed it. It takes a while, but it works on Windows and Linux.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: After moving bookmark it doesn't appear in new location → After moving bookmark folder it doesn't appear in new location
Summary: After moving bookmark folder it doesn't appear in new location → Bookmark folder moved into folder does not appear in new location
Status: REOPENED → ASSIGNED
PDT downgrading to P3 with [PDTP3] in status whiteboard
Priority: P1 → P3
Whiteboard: [nsbeta2-][FEATURE][rjc][nsbeta3+] → [nsbeta2-][FEATURE][rjc][nsbeta3+][PDTP3]
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.
Assignee: slamm → rjc
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-][FEATURE][rjc][nsbeta3+][PDTP3] → [nsbeta2-][FEATURE][rjc][PDTP3]
nsbeta3- in keeping with PDT rating.
Whiteboard: [nsbeta2-][FEATURE][rjc][PDTP3] → [nsbeta2-][FEATURE][PDTP3][nsbeta3-]
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
Whiteboard: [nsbeta2-][FEATURE][PDTP3][nsbeta3-] → [nsbeta2-]
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
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
hmmm, no chance for beta now. nominating for rtm. if someone minuses this bug I will
show up in person at their location, forthwith.
Keywords: rtm
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.
Keywords: helpwanted
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-][rtm-]
This is a DUP of a bug David/Eric are working on, I believe... David?
Assignee: rjc → hyatt
*** 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
Summary: Bookmark folder moved into folder does not appear in new location → Bookmark/Folder moved into open folder does not appear until collapse+expand
targetting moz1.0
Target Milestone: --- → mozilla1.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 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
grrr, VERIFIED Dupe of the newer bug.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.