127437 - [BRANCH ONLY] Moving bookmarks in personal toolbar places them in wrong position

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect)

Description

[SD]

Using build 2002022203, dragging and dropping bookmarks in the personal toolbar
puts them one place to the right of where they should be.

Comment 1

[Chris Lyon]

Confiming

Comment 2

[Pierre Chanial]

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

Comment 3

[Pierre Chanial]

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

Comment 4

[Chris Lyon]

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

Comment 5

[Jim Davis]

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

Comment 6

[Jim Davis]

Didn't see this when I created my duplicate.  Not entirely the same though;
looks like this happens in Win2k and Win98 as well.

Comment 7

[Pierre Chanial]

taking.
The indices of the elements of a RDF start from 1.
So there is no need to increment the index when calling InsertElementAt in
CreateBookmarkWithDetails and CreateFolderWithDetails.
The two methods (with an insertion index != -1) are called in bookmarkOverlay.js
(no need to modify it) and navigatorDD.js.
I modified the latter so that the insertion correctly performs for both:
- dragging bookmarks from the PT
- proxy icon
Requesting r=, sr=

Comment 8

[Pierre Chanial]

Attachment: patch v1.0

Comment 9

[Pierre Chanial]

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

Comment 10

[Pierre Chanial]

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

Comment 11

[Pierre Chanial]

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

Comment 12

[Pierre Chanial]

fix is now in bug 139471

Comment 13

[Pierre Chanial]

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

Comment 14

[Andreas Kunz]

Being annoyed by Bookmarks always appearing where I didn't expect them after
drag-and-drop (in Personal toolbar and in "Manage Bookmarks" - mostly they
appear one line above from where I placed them - this is one of my most hated
bugs nowadays) I looked around in bugzilla - and found a real jungle (including
this bug here) of open bugs describing the same:

bug 114256 (bookmark gets into wrong folder after dnd) although related, this
particular aspect is fixed now, but at least one of the dups is more general and
not adressed yet (bug 114878).

bug 114606 (bookmark goes to position above) describes exactly what I see and
hate, but in the meanwhile this bug has been somewhat changed into a tracking
bug and now also adresses other bugs related to bookmark d'n'd. (however,
component is not changed to "Tracking")
Many bugs that also describe the exact behaviour are duped to this one (I'll
list them later) because of its desription, but now nobody cares anymore about
the described problem because this one is now considered a tracking bug by some
people...

bug 119879 (bookmark appears one line above after dnd) is 100% what I see and hate.

bug 127437 (wrong position after dnd in personal toolbar) is about the same
problem just at another place (still mostly off-by-one after dragging bookmark).
Has *lots* of duplicates.

bug 137119 (bookmark positioned one line too high after dragging) is about
bookmark manager again, still the same problem. Was duped against bug 114606
already (same summary) but later reopened (bug 114606 is supposed to be tracking).

bug 139471 is finally about general dnd cleanup and is also supposed to fix this
particular issue I'm talking about. Very recently worked on, but now
unfortunately removed from RC2 list.


So it looks like (almost!) all of these six open bugs are duplicates of one
another, but correct duping and resolving was prevented by halfheartedly
changing bug 114606 into a tracking bug.
In addition the underlying bug I speak about (bookmark d'n'd results in wrong
position) was reported in many other bugs which are now duped to one of the six
bugs above: bug 115420, bug 116076, bug 117134, bug 120245, bug 122599, bug
130702, bug 137119, bug 130453, bug 130836, bug 132390, bug 134656, bug 137117,
bug 140071, bug 140342 and bug 140971 are the ones I found.


As you can see from the dup count or simply from imagining a browser where
bookmarks do not materialize where they are dropped, this is a quite serious
problem (and in my humble opinion should not go into 1.0). 

I think it would be a rewarding task for someone with the appropriate
permissions to clean up this jungle a bit. Maybe by clearly (and correctly)
labeling a general tracking bug and a separate one for the one particular d'n'd
problem I'm talking about (and duping the others against it).
This cleanup would get us rid of several ASSIGNED and NEW bugs and prepare the
way for fixing this one annoying d'n'd issue. 
Bug 139471 unfortunately was taken off the RC2 list (bug 138000) by Asa because
of its complexity. A simple "fix this one bug" wouldn't have been, I think.

Comment 15

[Eric Vaandering (no email)]

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

Comment 16

[mental]

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

Comment 17

[Pierre Chanial]

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

Comment 18

[Pierre Chanial]

fixed by the checkin of bug 139471

Comment 19

[Pierre Chanial]

Reopening this bug for the branch.
Trunk is already patched.

Comment 20

[Pierre Chanial]

Really reopening

Comment 21

[Blake Ross]

If this is fixed on the trunk then the correct thing to do is mark it
RESOLVED/FIXED. To get it on the branch, you add the adt1.0.1 keyword.

Comment 22

[Christopher Hoess (gone)]

ADT has nothing to do with non-NS contributors. email [e-mail] to ask
the patch be taken under consideration for the branch.

Comment 23

[Pierre Chanial]

I erroneously marked this bug nsbeta1+ instead of nsbeta1, removing the
nomination per Christopher comment if I understand correctly the logic. I will
mail the drivers.

Comment 24

[Pierre Chanial]

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

Comment 25

[Chris Lyon]

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