Closed Bug 202545 Opened 21 years ago Closed 20 years ago

Bookmark disappears when dragging/moving to a certain place on personal toolbar

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sedination, Assigned: durbacher)

References

Details

(Keywords: dataloss)

Attachments

(2 files)

first attempt
703 bytes, patch
janv
: review+
tor
: superreview+
Details | Diff | Splinter Review
full patch (first patch still valid as a smaller alternative fix)
1.42 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

In 1.4a, if you have some bookmarks on the Personal Toolbar and you drag one so
that it is JUST to the right of the "Bookmarks" folder, it disappears.
 

Reproducible: Always

Steps to Reproduce:
1. Click on a bookmark and drag it JUST to the right of "Bookmarks" folder
2. Try to drop it to the right side of the "Bookmarks" Folder

Actual Results:  
Bookmark disappears

Expected Results:  
Bookmark should be present at the right side of the "Bookmarks" Folder
Ignore my user-agent.  It works fine in 1.3.  The bug is present in 1.4a and
also in the April 15th nightly.
Still an issue ?
WFM 2003051708, Windows 2000
This is still an issue in 1.4RC1 on Windows XP

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529

You might have to attempt to do this several times to have the bookmark
disappear...the bookmark must be dragged in a certain "sweetspot" area JUST to
the right of the "Bookmarks" folder on the Personal Toolbar.
Confirmed:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030527

*** Bug 207480 has been marked as a duplicate of this bug. ***
JavaScript console produces the following Errors:

Error: [Exception... "Component returned failure code: 0x80070057
(NS_ERROR_ILLEGAL_VALUE) [nsIRDFContainer.InsertElementAt]"  nsresult:
"0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 1627"
 data: no]
Source File: chrome://communicator/content/bookmarks/bookmarks.js
Line: 1627

Error: [Exception... "Component returned failure code: 0x80070057
(NS_ERROR_ILLEGAL_VALUE) [nsIRDFContainer.InsertElementAt]"  nsresult:
"0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 1627"
 data: no]
Source File: chrome://communicator/content/bookmarks/bookmarks.js
Line: 1627

Error: uncaught exception: [Exception... "Component returned failure code:
0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIRDFContainer.InsertElementAt]" 
nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 1627"
 data: no]


This affects all OS.
OS: Windows XP → All
set OS to all
Brian, Jeff, Markus:
Do you still see this? And if so, could it be a duplicate of bug 88711?
Please check if you have deleted your Personal Toolbar Folder in Bookmarks and
set a folder as such.
Ok, I also see this on Win2k, describing the "sweet spot" more exactly: there
are two insertion lines between every two pt items and you have to choose the
left one of those at the right of the "bookmarks" folder.

JS errors (simultanous!) currently are:

Error: [Exception... "Component returned failure code: 0x80070057
(NS_ERROR_ILLEGAL_VALUE) [nsITransactionManager.doTransaction]"  nsresult:
"0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 1369"
 data: no]
Source File: chrome://communicator/content/bookmarks/bookmarks.js
Line: 1369

Error: [Exception... "Component returned failure code: 0x80070057
(NS_ERROR_ILLEGAL_VALUE) [nsIRDFContainer.InsertElementAt]"  nsresult:
"0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 1635"
 data: no]
Source File: chrome://communicator/content/bookmarks/bookmarks.js
Line: 1635
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 227420 has been marked as a duplicate of this bug. ***
Summary: Bookmark disappears when dragging on personal toolbar → Bookmark disappears when dragging/moving to a certain place on personal toolbar
Andreas: sorry for not answering your request, but I didnt't get any bugmail on
2004-01-25 from this bug... After a short peak into bug 88711, I don't think
that this is a duplicate
Well, in comment #9 I did not assume it anymore. This bug is fully valid.
This bug should be marked as "dataloss". Sorry, I don't have any privileges to
change the keywords.
one could argue, but... yes. Dataloss.
Severity: normal → critical
Keywords: dataloss
Ok, the point of failure is
http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFContainer.cpp#315
where the index is 0 when dropping to the "sweet spot".
Dropping to the insertion point just one or two pixels to the right has index 3
and does not fail.
(Dropping on the "Bookmarks" folder itself has index -1 but does not get that
far because it is aborted earlier)

The whole story starts at 
http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/resources/bookmarksMenu.js#404
there is also a second difference: the target of the event is not the first
bookmark in the toolbar, but still the bookmarks-button.
This has the effect that there is a different parent all the way, which ends in
http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/resources/bookmarks.js#1634
which has "NC:BookmarksRoot" as parent at the sweet spot while it's
"NC:PersonalToolbarFolder" otherwise.

So it's probably not only the index, but also the target of the drop, that's wrong.

Maybe this analysis helps some more experienced people solving the problem.

The possible (hacky) solutions that come to my mind are:
a) change the themes or navigator.xul to not have such an odd insertion point
b) deny dropping to that point (as it happens with the bookmarks folder)
c) catch the signature of that point and change drop data to the values of the
insertion point to its right
Attached patch first attempt — — Splinter Review 
Much easier than I thought: the drop target has to be recognized and mapped
correctly.
This patch makes dropping on the "Bookmarks" folder in the personal toolbar
itself work - this did not work previously (it made a "ping" sound and failed)!


That's not exactly this bug, but this patch also fixes the dataloss: dragging
to the "sweet spot" now silently fails, the dragged/dropped bookmark not moved.


BTW: there is a second dataloss sweet spot to the left of the "Bookmarks"
folder. This is also fixed by this patch.
And all of this with only three lines added, I'm proud... ;-)

However, I'll try to improve behaviour when dropping to the sweet spots. Not
sure what to do exactly... the left one should probably disallow dropping, the
right one should drop to the toolbar, not into the "Bookmarks" folder...
This patch fixes this bug completely.
The first patch is extended to also provide a drop target when the insertion
point is one of the sweet spots to the left/right of the "Bookmarks" folder on
the PT.
In both cases the dragged item is placed at the very left (as first item) of
the personal toolbar which seems reasonable to me.
Comment on attachment 140250 [details] [diff] [review]
full patch (first patch still valid as a smaller alternative fix)

Requesting r= from pch.

If you don't like this patch, please have a look at the first patch which fixes
the dataloss and makes dropping bookmarks on the "Bookmarks" folder possible by
just adding that additional "case" that should have been there in the first
place. That patch you _have_to_ like and is surely good to have. ;-)
Attachment #140250 - Flags: review?(p_ch)
Blocks: 232375
Attachment #140244 - Flags: review+
Attachment #140250 - Flags: review?(p_ch)
Comment on attachment 140244 [details] [diff] [review]
first attempt

Requesting sr= from tor@acm.org.
Really small and simple patch for dataloss bug, so maybe it's possible before
freeze? :-)
Attachment #140244 - Flags: superreview?(tor)
Assignee: bugs → durbacher
Attachment #140244 - Flags: superreview?(tor) → superreview+
Checking in xpfe/components/bookmarks/resources/bookmarksMenu.js;
/cvsroot/mozilla/xpfe/components/bookmarks/resources/bookmarksMenu.js,v  <-- 
bookmarksMenu.js
new revision: 1.10; previous revision: 1.9
done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
I can verify this as fixed, using Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7a) Gecko/20040215. Thanks! :)
Verifying per last comment and own testing.

Bug 234571 was filed for taking care of the two insertion points to the left and
right of the "Bookmarks" folder where dataloss occurred earlier and now drag and
drop silently fails to do anything (i.e. what the second patch also addressed).
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.