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
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.
moving to places
Component: Bookmarks → Places
QA Contact: bookmarks → places
Flags: blocking-firefox3? → blocking-firefox3+
Neil, are you interested in fixing this one too?
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.
Depends on: 337761
Priority: P5 → P4
Target Milestone: Firefox 3 Mx → Firefox 3 M11
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.
OS: Windows XP → All
Hardware: PC → All
Summary: 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 → 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
Version: unspecified → Trunk
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.
Not blocking, but wanted. Bug 403209 does, however, block, so if this fixes that one, win-win!
Flags: blocking-firefox3? → blocking-firefox3-
(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.
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.
Keyboarding through the interface seems to be working for me.
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.
Due to this is a regression bug it cannot be an RFE - updating Serverity to normal.
Severity: enhancement → normal
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.
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).
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!
Flags: blocking-firefox3- → blocking-firefox3?
(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 ?
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
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.
(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.
Supposedly, bug 419740 is now fixed in the latest hourly. Give that hourly a test and see what you then get for this bug.
Flags: blocking-firefox3? → blocking-firefox3-
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?
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).
(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).
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.
tentative fix with patch in bug 418671 Can someone check if this is actually FIXED or what is missing in nightly build 20080920033605?
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
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [Fixed by bug 418671]
Target Milestone: --- → Firefox 3.1b1
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.
(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
(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)
(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?
(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.
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.
Flags: in-litmus? → in-litmus+
(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.
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.