User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/00200508 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/00200508 Firefox/1.0.6 This is a port of bug 230563 (of Seamonkey) to Firefox, because it exists in Firefox too, and a patch was written for it. Reading from the bug's description: This is a comment or elaboration on a problem that has already been reported by a number of informants. There's a basic shortcoming with the way that pasting of bookmarks appears to be intended to operate for the Mozilla user. Rather than Ctrl-V inserting the cut/copied item *before* the highlighted line in Bookmark Manager, it would make more sense if Ctrl-V emulated the behaviour of Netscape 4.x and inserted the cut/copied item *after* the highlighted line. Netscape 4.x had it right in the first place as far as pasting behaviour in the Bookmark Manager was concerned: 1. If you pasted to an open (expanded) folder, the cut/copied item was pasted *into* that folder, as its first item. 2. If you pasted to a closed (collapsed) folder, the cut/copied item was pasted immediately below that folder (but not into it), at the same level of nesting within the bookmark hierarchy as that folder. 3. If you pasted to the last item in a folder, the cut/copied item got inserted after it to become the new last item within that folder. (You can't do that in Mozilla with pasting, nor with keyboard shortcuts.) 4. If you pasted to the pseudo "Bookmarks for <whoever>" folder -- whether it was open or closed -- the cut/copied item because the very first displayed bookmark. Intuitive and consistent -- and if the pasting behaviour of Mozilla wasn't intended to emulate that of Netscape 4.x, then it would be great if Mozilla *did* emulate Netscape 4.x in that regard. (Because -- disregarding Mozilla's multiple bookmarks -- Netscape 4.x had the best bookmark manager around.) Reproducible: Always
Created attachment 190542 [details] [diff] [review] A Patch to correct the problem. This is a patch that corrects this bug in Firefox CVS. It still has an issue of traversing the rest of the folder from the item, because I believed it was a problem, while in fact it wasn't.
Hey Shlomi, you need to request review from someone else, not from yourself :) For this Firefox bug firstname.lastname@example.org would be a good choice, although he might have a busy schedule so you'll have to wait. For Mozilla/SeaMonkey you'd need someone else.
Comment on attachment 190542 [details] [diff] [review] A Patch to correct the problem. Caleb: thanks, I've changed the requestee to mconnor.
Created attachment 224309 [details] [diff] [review] New Version of the Patch with some needles code removed. This is a new version of the patch that eliminates some code that was added in the course of the patch' debugging, that wasn't really needed. The patch works fine without the removed code.
*** Bug 359436 has been marked as a duplicate of this bug. ***
After more than 6 months, I'd switch reviewers...
(In reply to comment #6) > After more than 6 months, I'd switch reviewers... > To whom do you suggest I switch my assigned reviewer? I barely know anyone here. And for the record, I don't understand why I have to assign a reviewer in the first place. Why can't all potential reviewers search for all patches submitted in their categories, and handle them in a queue-like fashion. Regards, Shlomi Fish
Comment on attachment 224309 [details] [diff] [review] New Version of the Patch with some needles code removed. Switching reviewer to mano.
Comment on attachment 224309 [details] [diff] [review] New Version of the Patch with some needles code removed. Hi Shlomi, thanks for you work. I'm canceling the review request here mostly because the code in question will be disabled sometime soon (in favor of places) and it's unlikely that we'll take this fix for 2.0.0.x.
(In reply to comment #9) > (From update of attachment 224309 [details] [diff] [review] ) > Hi Shlomi, thanks for you work. I'm canceling the review request here mostly > because the code in question will be disabled sometime soon (in favor of > places) and it's unlikely that we'll take this fix for 2.0.0.x. > OK, thanks for letting me know. Regards, Shlomi Fish
not going to take further fixes on 2.x, feel free to reopen if you can reproduce on 3.x or current trunk