243961 - When dragging a bookmark in the personal toolbar to the overflow menu it does not open when never dragged anything before

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect)

Description

[Andreas Kunz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514

This problem is left from bug 201854.

Reproducible: Always
Steps to Reproduce:
1. Restart Mozilla completely
2. Make sure to have enough bookmarks in the personal toolbar so some go to the
overflow menu
3. Drag a bookmark from the personal toolbar (or whereever) to the chevron (the
">>" sign that opens the overflow menu)
Actual Results:  
It should expand so you can place the bookmark at the desired position inside.

Expected Results:  
It does not open, you can release the bookmark, but it is always placed to the
second from last or last position in the overflow menu.

Strangely, if you did any drag-and-drop action on the personal toolbar before,
this works. This is probably also, why I did not spot this problem earlier.

Comment 1

[Andreas Kunz]

Attachment: patch

The problem is that getBTOrientation does not know the "bookmarks-chevron" as a
drop target yet, while it really should. Mostly it says the bookmark is dropped
before or after the chevron itself and then
   aTarget.lastChild.showPopup(aTarget);
is not called because
   if (this.mCurrentDropPosition == BookmarksUtils.DROP_ON && [...]
is false.

This is caused by isBTContainer claiming the chevron is no container:
getBTOrientation in this case only allows drops before and after the item, not
*on* it.
After the first drop action the chevron suddenly *does* have the "container"
attribute (it happens during moveSelection in bookmarks.js, more exactly during
the call in line 1635, some levels deeper). 
Therefore drops *on* it are allowed afterwards.

This patch makes drops to the chevron always happen *on* it, thus opening it. I
think this is the best behaviour because it makes no sense to drop an item to
its right and if you want to drop to its left you don't need to hit those 1-2
pixels of border that would make it drop there (it wouldn't work anyway because
the item would still go *into* the overflow menu, as second from last item).

I also considered additionally making the "bookmarks-chevron" have the
attribute by explicitly setting it in navigator.xul, but it's not really
needed. If it is desired, just say it and I'll produce a patch with it.

Comment 2

[Andreas Kunz]

Comment on attachment 148765 [details] [diff] [review]
patch

Requesting r= from Neil.
Would be nice if this could go into 1.7...

Comment 3

[Andreas Kunz]

Comment on attachment 148765 [details] [diff] [review]
patch

Requesting sr= from alecf.

Comment 4

[jag (Peter Annema)]

Comment on attachment 148765 [details] [diff] [review]
patch

sr=jag

Comment 5

[Andreas Kunz]

Comment on attachment 148765 [details] [diff] [review]
patch

Requesting approval for 1.7.

This is very low risk and quite visible because it happens when trying to us a
new feature for the first time.

Comment 6

[Asa Dotzler [:asa]]

Comment on attachment 148765 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.7

Comment 7

[[e-mail]]

Fix checked in to branch and trunk.

Comment 8

[baffclan]

I cannot reproduce 2004052208-trunk/WinXP-JA.
thanks for fixing this.

Comment 9

[Andreas Kunz]

Verified per last comment and own testing with current trunk nightly.