Closed Bug 129428 Opened 23 years ago Closed 23 years ago

Paste doesn't work in bookmark manager

Categories

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

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: relf, Assigned: bugs)

References

Details

(Keywords: dataloss, qawanted, relnote, Whiteboard: [driver:asa] [ETA 5/07] [m5+])

Attachments

(1 file, 2 obsolete files)

i am a fool
3.94 KB, patch
p_ch
: review+
jag+mozilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.9+) Gecko/20020306 BuildID: 2002030616 Ctrl+X followed by Ctrl+V doesn't work in Bookmark manage window. It cuts current bookmark on Ctrl+X (Cut), but doesn't insert in on Ctrl+V (Paste) Reproducible: Always Steps to Reproduce: 1. Go to Manage Bookmark 2. Try to move some bookmark by Ctrl+X & Ctrl+V 3.
I see this on Windows as well. Paste seems to work every once in a while but most of the time it does not.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OS/2 → Windows ME
Hardware: PC → All
Yesterday this bit me (Win98 build 2002022603), and I lost 4 bookmarks at once trying to cut and paste them. What makes this worse is that this is my first recourse when drag & drop stops working correctly. I think it's a dup of a bug I can't find again, where context menus stop working correctly after a while in the Bookmark Manager. All/All. Cut - paste = dataloss.
Keywords: dataloss
OS: Windows ME → All
norton, you're thinking of bug 121172.
*** Bug 131250 has been marked as a duplicate of this bug. ***
Reproduced, 0.9.9/WinXP. This causes dataloss, possibly badly (what if someone selects all 100+ of their bookmarks and tries to cut/paste them somewhere?). Nominating for mozilla1.0. If we can't fix this for 1.0 then cut functionality should be disabled on bookmarks. Note also that from bug 85469 (a bug regarding bookmarks cut/paste reported on Win98, where it behaved strangely but didn't cause dataloss) we know this -was- working at some point.
Keywords: mozilla1.0
*** Bug 131667 has been marked as a duplicate of this bug. ***
resummarizing to make easier to find
Summary: Ctrl+X/Ctrl+V in Manage Bookmarks don't work → Paste doesn't work in bookmark manager
I'm getting related strangeness with copy - for the *second* time I try to do it. Steps to reproduce: 1. Hit ^B (open bookmarks) 2. Select a bookmark 3. Hit ^C (copy) 4. Move highlight to a folder in your bookmarks 5. Hit ^V (paste) (All OK so far!) 6. Select the same bookmark (from step 2) again 7. Hit ^C 8. Move highlight to a folder 9. Hit ^V (Nothing appears to happen!) I think I've got the pattern here - each bookmark can only be copied and pasted *once* - try to copy it again and it doesn't work. However, I can try with another bookmark and it works fine - once. It gets worse... 10. Select the bookmark from step 6 again 11. Hit Delete (The new bookmark created in step *9* appears to be deleted!) 12. Close and re-open bookmarks (Now, we see that the correct bookmark *was* deleted in step 11 - the bookmark from step 9 is still there!) Behaviour resets when bookmark window is closed and reopened. This is 0.9.9, on Win2K.
Keywords: nsbeta1
nsbeta1-, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha
*** Bug 133291 has been marked as a duplicate of this bug. ***
*** Bug 134391 has been marked as a duplicate of this bug. ***
*** Bug 135703 has been marked as a duplicate of this bug. ***
*** Bug 135787 has been marked as a duplicate of this bug. ***
With build 2002040403 what I see is that paste after copy doesn't work at all, opposite to what is reported in the comment #8 before.
*** Bug 136167 has been marked as a duplicate of this bug. ***
I can confirm original bug with Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020409(03) I cannot confirm Problem Russell Odom 2002-03-18 02:20
Recreated on Windows 2000 - Netscape 6.2 and latest Mozilla build. Can not paste bookmark in bookmark manager. I lost an entire folder (luckily I had a backup of bookmark.htm). This has been a problem for a long time, and it will not be fixed soon, I agree with the suggestion : DISBALE CUT AND PASTE
Why is this set to a target milestone of 1.2? It's a serious bug. It needs addressing sooner.
This is insanely serious dataloss. Cut (and copy) should be disabled. Undo doesn't work eaither... Cut now functions as undoable delete. This is beyond bad. Since you can't move bookmarks with drag scroll, I tried to move a bunch with cut. One would assume a feature enabled days before a 1.0rc is due would not cause instant and obvious dataloss 100% of the time.
Confirming bug in WinME in build 2002041710 and just cast a vote for this bug. I use keyboard shortcuts all this time, and this one is a, um, bugger. - Ray B.
I can't believe this serious bug that causes heavy dataloss and it's easily reproducible is still present in 1.0 RC-1 and it's scheduled for 1.2alpha. Also, its solution should be rather trivial since it's basically a cut and paste in the bookmarks.html file. Or, anyway such feature should be disabled until fixed, as remarked in Comment #5 and Comment #19 I'm voting for this bug.
I reproduced this, Win2000, Mozilla1.0RC1. I disjoint-selected several bookmarks, CUT, PASTE into a folder in the bookmark manager, but they didn't show up. I was able to paste them into Notepad. This is a _bad_ situation. If we can't fix it before 1.0, disable the CUT menu option and keyboard shortcut.
*** Bug 138553 has been marked as a duplicate of this bug. ***
I think that dataloss bugs are much more dangerous than any browser crash and must be corrected before the 1.0 release. So their priority must be set as critical as soon as they are confirmed.
Just to add to the general rumblings here guys - I concur that this kind of dataloss bug is worse in some ways that a crash...heck, it's cut and paste, not rocket science!! This is the exactly the kind of thing that will turn new users away, despite Mozilla's many unique joys, because in real software products, this kind of stuff JUST WORKS! So I'm voting that this be retargeted at moz1.0. Also, it seems very odd that the priority has shifted regarding functionality in the bookmark manager. It used to be that drag'n'drop didn't work - which was an inconvienience, but not a disaster - but now we have a situation that d'n'd seems fairly sorted, but we can't cut and paste or undo - its a joke (on us)!
Renominating nsbeta1, approving for anyone to work on a fix for mozilla1.0. /be
Keywords: mozilla1.0, nsbeta1- → mozilla1.0+, nsbeta1
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
This might not make 1.0. Nominating for 1.0.1 if necessary. Proposed relnote: In Bookmarks Manager, the "cut" operation does work, but the "paste" operation does not. Do not use "cut" in Bookmarks Manager. If you do so by mistake, try to "paste" into a text editor.
Keywords: mozilla1.0.1, relnote
Is there _really_ no simple way (js modification, or disable a few lines of code) to disable cut from Bookmark Manager ?
I agree, you KNOW not everyone will read the release notes. If you leave the "Cut" functionality in with no (or little) comment, it's going to be embarrassing. I too lost several bookmarks to this bug.
I tried to disable the cut by removing line 350 of bookmarksOverlay.js and making it equivalent to a copy operation. http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/resources/bookmarksOverlay.js#350 348 case "bm_cut": 349 this.copySelection(selection); 350 this.deleteSelection(selection); 351 break; but alas with no result. Removed xul.mfl, still no result. Still, it really looks like this is where the cut functionnality is implemented, I don't get what I'm missing. It's not the the first time I think I understand what some js inside mozilla is doing only to be proven otherwise. This is really frustrating.
Thank you very much for working on this bug. Maybe try taking a big chunk of the code out? It might break stuff, but at least we'd have a patch to fix this bug. I'd say it's important enough to do that.
I have a "fix" for this bug. Jean-Marc: its in bookmarks.xml... The bookmarks module is a total mess! It desperately needs a rewrite - I spent a few hours creating a fix for bug 138523, and have found all these other bugs in the bookmarks module. The module is actually split into two parts: <br> The "Manage Bookmarks" window is coded almost entirely in bookmarks.xml<br> The Personal Toolbar is coded in personalToolbar.js relying on many functions in bookmarksOverlay.js<br> I'm trying to create a patch diff file, but having trouble and don't have much time to work on it right now...
I noticed this on OpenVMS build from 20020419 and confirmed it on Linux build 2002041711 before I realized that there was a bug already opened for this.
Leo, can you attach your fix to this bug please. We need to get review and super-review quickly if this is going to make it into Mozilla 1.0. Thanks.
Leo has attached his patch to bug 138523. It's attachment (id=81489) http://bugzilla.mozilla.org/showattachment.cgi?attach_id=81489
Note that Leo's patch will disable cut. Eventually, we should enable both cut and paste. That won't make 1.0, obviously. Thank you Leo!
um, paste used to work. we should probably figure out what broke.
ben's going to take a look at this tonight. If he can find a fix we'll try to get it in. If he can't or the fix is scary then we'll disable cut to prevent the dataloss.
Whiteboard: [driver:asa]
Attached patch patch (obsolete) — — Splinter Review
I think rjc got a little carried away in GetSynthesizedType :-) Well, maybe not, but he calls IsBookmarkedInternal, which checks to see if the node we're checking type for has any ordinal arcs in (basically asking, "is this bookmark in a container?"...) in the case of Paste after Cut, the bookmark has been *removed* from its previous container during the Cut operation, so that when we try to get its type in the Paste, it does not appear to be a valid bookmark by IsBookmarkedInternal's strict standards. I've removed this check so as to avoid this problem. I don't think the impact will be tremendous.
Who can review this? Time is short. We need quick turnaround with r and sr.
Keywords: nsbeta1- → nsbeta1+
Whiteboard: [driver:asa] → [driver:asa] [ADT1]
Comment on attachment 82010 [details] [diff] [review] patch r=brade
Attachment #82010 - Flags: review+
I support fixing paste rather than disabling cut since that fix might be incomplete if there is copy and delete/clear functionality accessible.
Comment on attachment 82010 [details] [diff] [review] patch sr=blake
Attachment #82010 - Flags: superreview+
I tested this patch: cut and paste does not work for folder. In a debug build, I get the following assertion: ###!!! ASSERTION: null ptr: 'aURI != nsnull', file nsRDFService.cpp, line 993 ###!!! Break: at file nsRDFService.cpp, line 993 ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetResource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://communicator/content/bookmarks/bookmarks.xml#bookmarks-tree.paste() :: paste :: line 62" data: no] ************************************************************ An error occurred executing the cmd_bm_paste command
Keywords: adt1.0.0
Whiteboard: [driver:asa] [ADT1] → [driver:asa] [ADT1] [ETA 05/03]
Jag, could you have a look at this too?
Whiteboard: [driver:asa] [ADT1] [ETA 05/03] → [driver:asa] [ETA 5/03]
Target Milestone: mozilla1.2alpha → mozilla1.0
*** Bug 141873 has been marked as a duplicate of this bug. ***
Attached patch patch to fix folders as well (obsolete) — — Splinter Review
Some functions in bookmarksOverlay.js were being called with strings instead of nsIRDFResources as parameters. Oops. This was preventing copy/cut of folders from working.
Attachment #82010 - Attachment is obsolete: true
Removing adt1.0.0 until the new patch is reviewed.
Keywords: adt1.0.0
Attached patch i am a fool — — Splinter Review
Attachment #82164 - Attachment is obsolete: true
Comment on attachment 82183 [details] [diff] [review] i am a fool r=pierrechanial@netscape.net with the indent correction and hunk#2 in bookmarksOverlay.js pb as discussed
Attachment #82183 - Flags: review+
Samir - Can you sr= this one?
*** Bug 142056 has been marked as a duplicate of this bug. ***
Making this a [m5+] stopper. Jag, and Samir can you look at this one. We'd like to take it today, if possible.
Whiteboard: [driver:asa] [ETA 5/03] → [driver:asa] [ETA 5/03] [m5+]
Comment on attachment 82183 [details] [diff] [review] i am a fool sr=jag
Attachment #82183 - Flags: superreview+
ADT would like this to land on the trunk today, and bake for a day or two. Claudius, would you please test it to verify that it works, and has no regressions?
Keywords: qawanted
Priority: -- → P1
Keywords: adt1.0.0
Whiteboard: [driver:asa] [ETA 5/03] [m5+] → [driver:asa] [ETA 5/05] [m5+]
Reproduced bug on OS X in RC1. Drag and drop works poorly, at least on OS X, (it's hard to get the window to scroll) so this is a major impediment to being able to organize book marks. I would vote for making this a priority, if feasible.
fruit1: This patch has nothing to do with D&D, well, it doesn't help or regress the current D&D problems. Did you mean one of the other D&D bugs? As soon as I can get network connectivity restored to my laptop I will land this fix (later tonight).
Status: NEW → ASSIGNED
Comment on attachment 82183 [details] [diff] [review] i am a fool a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82183 - Flags: approval+
Sorry, I wasn't clear. What I was trying to say is that I'd support the cut and paste problem being prioritized since, at least on OS X, drag and drop doesn't work well on Mozilla so it's difficult to organize bookmarks without having cut and paste as an alternative. Optimizing DnD would work too.
Checked in to trunk
Thanks jag. I have it in my branch tree ready to go for when it gets adt1.0.0+
Peter, Ben, Can you please resolved this bug as "Fixed" if it has been checked into the trunk. Thanks,Gayatri
Whiteboard: [driver:asa] [ETA 5/05] [m5+] → [driver:asa] [ETA 5/07] [m5+]
Resolving as fixed, because it is fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 140463 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
VERIFIED Fixed with 2002050703 trunk build
adding adt1.0.0+. Please check this into the branch today and add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Keywords: fixed1.0.0
*** Bug 142985 has been marked as a duplicate of this bug. ***
*** Bug 143069 has been marked as a duplicate of this bug. ***
Confirmed data loss in v1.0 RC2 build 2002051006 win98
Worksforme in 1.0 RC2 branch Build ID: 2002051006 Windows 98SE. Valerio Capello, please post the steps that you took to reproduce the problem. Right-click cut and right-click paste work for me in Bookmarks manager. Ctrl-x cut and Ctrl-v paste work for me. Shift-del and Shift-ins do not work, however. Bug 143735. Having more than one bookmark with the same name is not currently supported. Bug 51683. Make sure you are testing with a unique bookmark.
Sorry, it's actually a wfm v1.0 RC2 build 2002051006 win98 I've probably tried it with already bookmarked pages.
Actually, bug 51683 is about multiple bookmarks having the same URL; reusing the same name should not be a problem.
I think the problem is that the bookmark management is buggy in more than one way: sometimes it happens (including with drag'n'drop) that the bookmark you've moved is not shown, but it's in fact there. Of course this is a different bug, but I'm only trying to figure out why I've confirmed the apparently data loss.
*** Bug 143846 has been marked as a duplicate of this bug. ***
Verified fixed on Openvms build 20020513 (rc2)
Patch http://bugzilla.mozilla.org/attachment.cgi?id=82183&action=view breaks native bookmarks (import) functionality on BeOS x86 platform (bug 145858). mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp nsresult nsBookmarksService::GetSynthesizedType(): blind type definition as aType = isContainer ? kNC_Folder : kNC_Bookmark; is very wrong for BeOS...because if it isn't container-folder, it may be with 99% probability file containing bookmark in attribute...this is way BeOS manages bookmarks
Blocks: 145858
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: