395176 - Bookmarks menu and bookmarks toolbar menus should remain and stay open (should be sticky) when rearranging (dragging and dropping, moving around,changing folder) bookmarks until you click away

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P4)

Description

[mmortal03]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090304 Firefox/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090304 Firefox/3.0a6pre

Bookmarks menu and bookmarks toolbar menus should remain and stay open (should be sticky) when rearranging (dragging and dropping, moving around) bookmarks, until you click away.

Another bug fix recently added this feature for when we delete bookmarks.  This feature should also be present for when dragging bookmarks around.

Reproducible: Always

Comment 1

[Daniel.S]

This is actually a regression caused when Bookmarks on Places were enabled. Sorry, I don't know the exact time. But when Placec was disabled for one build this was working and regressed again when Places was finally enabled.
Comments 53-61 of bug 195031 may be interesting here.

This bug should be a blocker because users are no longer able to easily/quickly rearrange bookmark items in their menus.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

moving to places

Comment 3

[Jesse Ruderman]

Neil, are you interested in fixing this one too?

Comment 5

[Neil Deakin]

This is caused because the timer at dragexit which closes popups you're not dragging over, closes the popup. The dragging over bookmarks is broken anyway (see PlacesMenuDNDObserver), which in turn needs bug 337761 fixed.

Comment 6

[Gabriel Chadwick]

This is my most annoying bug in Firefox 3. It is a very important lost of functionality. It makes adding a bookmark more difficult most the time. Rearranging in the bookmark menu is almost impossible. I really think the severity, blocker status, and priority of this bug demonstrates a misunderstanding of the real scope of it. Not enhancement to me it is a major regression. It should block and be more then P4 witch in my understanding is a bug that can by dropped for final release. This should not be dropped. 

Comment 7

[Ian Macfarlane]

As I commented in bug 403209, if you go to bookmark a page, and click on the list of folders to put the bookmark in, and the one you want isn't there, you can't then click on the arrow to the right (which provides the drop down list of all bookmark folders), because this bug makes the entire window disappear (as does switching focus to anything else in the window).

This is a major bug which really has to be fixed before release.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, but wanted. Bug 403209 does, however, block, so if this fixes that one, win-win!

Comment 9

[mmortal03]

(In reply to comment #8)
> Not blocking, but wanted. Bug 403209 does, however, block, so if this fixes
> that one, win-win!
> 

Unless I am missing something, these bugs deal with inherently different parts of Firefox.  This bug deals with dragging items around in the same menu area and asking that the menu stay open, something that Firefox had done for a brief period of time, but then regressed, but has never really been the default behavior.  That other bug deals with clicking away from a dropdown list closing MORE than just the dropdown list, where not having this buggy behavior has always been the default.

Comment 10

[Neil]

I'm on beta2, and this is a huge problem (especially since I make copious use of Bookmarks, contrary to the paper cited in the wiki). Between my inability to drag & drop bookmarks into folders in the organizer, and the inability to put bookmarks in the right folder to begin with, I have virtually no ability to continue to expand my bookmark collection.

Comment 11

[Neil]

Keyboarding through the interface seems to be working for me.

Comment 12

[Ria Klaassen (not reading all bugmail)]

I did a search for the regression range and I had to go back to April 2006, so this was before the ThreadManager bug.
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-04-10+02%3A00&maxdate=2006-04-10+23%3A00
There are two bookmarks menu D&D bugs in this range. 
A check on 9 May (the day before the checkin of ThreadManager bug 326273) showed that this bug was not yet fixed.
In this 9 May build I saw that the bookmarks menu closed after dropping, but when I first dragged a favicon into the menu, the behaviour changed and from now on the menu stayed also open after other D&D operations.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Due to this is a regression bug it cannot be an RFE - updating Serverity to normal.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

At least this is working for the bookmarks toolbar under OS X with the todays trunk nightly build. Bookmarks menu and other OS are still closing when dropping an item.

Comment 15

[Daniel.S]

Mozilla/5.0 (Windows; U; Windows NT 6.0 en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre ID:2008022806

This bug seems to be partially fixed, however there are still three problematic cases:

#1 After a fresh start, when I try to drag around an item in the Bookmarks Menu the first time it collapses (This could be Bug 419740).

#2 When I drag an item from the Menu root into a subfolder, the subfolder collapses (it stayed open in Fx2). The menu correctly stays open.

#3 When i drag an item from a subfolder into another subfolder, the entire menu collapses (everything stays open in Fx2).

Since all those infamous bugs (Bug 337761 for example) are fixed now, this one shouldn't be a problem (and make it into Fx3).

Comment 16

[(mostly gone) XtC4UaLL [:xtc4uall]]

the in the comment #8 mentioned and +blocking marked Bug 403209 has been duped to Bug 400019 which is fixed, but the in comment #c0 described problem persists nevertheless.
because of this and the latest comments here (e.g. #c15) -> re-nom for blocking status and rasing priority!

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #15)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre] (nightly) (W2Ksp4)

I seem unable to reproduce the comment 0 bug.
Could you/someone check whether or not bug 389931 did fix (in Gecko/2008022704) this bug ?

Were your 3 problematic cases there before that fix or are they regressions of it ?

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Even while bug 419740 is not fixed in todays nightly build I cannot reproduce this issue anymore. During the first action the menu closes due to bug 419740 but any subsequent drag&drop actions are leaving the bookmarks menu open

Comment 19

[Daniel.S]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008030107
Minefield/3.0b4pre ID:2008030107

Bug 419740 is fixed; however, I still encounter the problems #2 and #3 of my comment #15.

As said, this Bug is partially fixed, but there are still situations in which the menu is closing although it shouldn't.

Comment 20

[mmortal03]

(In reply to comment #18)
> Even while bug 419740 is not fixed in todays nightly build I cannot reproduce
> this issue anymore. During the first action the menu closes due to bug 419740
> but any subsequent drag&drop actions are leaving the bookmarks menu open
> 

I see the same, as long as you do drop it back somewhere allowable.  However, if you drag a link, and the menu disappears on you, and then you don't go back in and try to drop it back into that menu, but, instead, release it somewhere where the mouse won't let you drop it (the mouse turns into a  "cannot drop" symbol), the next time you go into a menu, the disappearing menu problem still occurs.

So, only if you first drop a bookmark somewhere allowable does this problem go away.  Furthermore, for any bookmark toolbar folder that you drag from, the next time you hover over that folder, the button for it is already depressed, until you click it again.  That is Bug 225434, and may be related.

Comment 21

[mmortal03]

Supposedly, bug 419740 is now fixed in the latest hourly.  Give that hourly a test and see what you then get for this bug.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yeah, it works perfectly now with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030305 Minefield/3.0b4pre ID:2008030305

Anyone who could run a test on Linux so we could marking this bug fixed?

Comment 23

[mmortal03]

It is still broken in certain cases when dragging between sub-menus.  

Furthermore, if you right-click somewhere in a bookmark menu, and then right click again somewhere else inside of it, it should remain open, the first context menu should close, and the second context menu for where you just right clicked should open.

Also, if you right click in a menu, and then left click on a folder inside that menu, the right click context menu should close, but the folder should remain open (expanded).

Comment 24

[Daniel.S]

(In reply to comment #22)
> Yeah, it works perfectly now with Mozilla/5.0 (Windows; U; Windows NT 5.1;
> en-US; rv:1.9b4pre) Gecko/2008030305 Minefield/3.0b4pre ID:2008030305

Are you sure? #2 and #3 of comment #15 are still reproduceable for me in the latest nightly with a new profile.

If it really works on your side (please test), then it may be a Vista-Problem (on which I am).

Comment 25

[Marcos]

Hi, I was going to report on this bug but have just found this report here that dates back to 2006. Hope some day this will be fixed, it's one of the very few things that annoy me about Firefox.

Comment 26

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

tentative fix with patch in bug 418671
Can someone check if this is actually FIXED or what is missing in nightly build 20080920033605?

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002020319

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002033404

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As Marco pointed out on IRC we don't have d&d tests yet. Means, we should add this d&d behavior as a testcase on Litmus.

Comment 29

[Shawn Wilsher :sdwilsh]

(In reply to comment #28)
> As Marco pointed out on IRC we don't have d&d tests yet. Means, we should add
> this d&d behavior as a testcase on Litmus.
But we do have a means of testing this stuff now I think:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js#417

Not used anywhere yet though

Comment 30

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to comment #29)
> But we do have a means of testing this stuff now I think:
> http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js#417
> 
> Not used anywhere yet though

that's interesting, so i think we should still create litmus tests, and then file a bug to convert litmus d&d test to automatic ones (i would have preferred mozmill, but if this works, could still be good)

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #30)
> that's interesting, so i think we should still create litmus tests, and then
> file a bug to convert litmus d&d test to automatic ones (i would have preferred
> mozmill, but if this works, could still be good)

Marco, having mozmill tests will take a while and for now mozmill isn't accessible from the test harness. So no automated tests are possible for tinderboxen. The question is how long we can wait for those tests?

Clint, do we have an estimate when we want to see mozmill included in the test harness and automatically run?

Comment 32

[cmtalbert]

(In reply to comment #31)
> (In reply to comment #30)
> > that's interesting, so i think we should still create litmus tests, and then
> > file a bug to convert litmus d&d test to automatic ones (i would have preferred
> > mozmill, but if this works, could still be good)
> 
> Marco, having mozmill tests will take a while and for now mozmill isn't
> accessible from the test harness. So no automated tests are possible for
> tinderboxen. The question is how long we can wait for those tests?
> 
We can have the tests written and run manually now.  That's the same level of testing that we have if we have litmus tests, so all we need to do is write them.  Of course, having automated tests run automatically is the better goal.

> Clint, do we have an estimate when we want to see mozmill included in the test
> harness and automatically run?
That work is ongoing and is being performed in bug 457265.  I think the only thing from blocking it is the update mechanism for the mozmill python components.  So, probably the next few weeks we'll have the ability to turn it on, and then we'll have to get slaves set up and what not with releng to run these tests, and so it will probably be a month or two to get all the pieces in place.

Comment 33

[Aakash Desai [:aakashd]]

Test case https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=7457 was updated to reference this additional bug Id for regression testing.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #32)
> We can have the tests written and run manually now.  That's the same level of
> testing that we have if we have litmus tests, so all we need to do is write
> them.  Of course, having automated tests run automatically is the better goal.

Yeah. This is a BFT test. Can probably happen after we have finished the smoketests.

Comment 35

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv