251147 - Empty bookmark menus don't hide Empty tag if user adds to the menu while it is open

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I could've sworn I checked in a patch for this, but I guess not; I think I have
one kicking around.  If the user drags to an Empty menu, the Empty item never
disappears because the code only looks for the last item to be Empty.  It really
should be looking for the first item; all ways to add to a menu while the menu
itself is open append to the menu.

Need to figure out if there's a requirement that commands should execute before
a xul menu gets closed -- this is leading to visual quirks if a menu is modified
while it's open (e.g., even once the bug above is fixed, the new item will still
show up briefly after Empty before the menu is closed).

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: bookmarks-drag-to-empty-0.patch

fix

Comment 2

[Mike Connor [:mconnor]]

Comment on attachment 153381 [details] [diff] [review]
bookmarks-drag-to-empty-0.patch

>-    if (aTarget.lastChild.id == "empty-menuitem")
>+    // if the user drags to the menu while it's open (i.e. on the toolbar),
>+    // the bookmark gets added after the Empty menu item before the menu
>+    // is hidden.  We need to test for firstChild in this case, and also
>+    // lastChild should we ever support dragging to a specific position
>+    // in a menu

you know that on Windows we can drag to specific locations, right?  unless of
course, you broke that ;)

fix the comment to reflect that and r=me :)

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

in on aviary, with fixed comment :)

Comment 4

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change