Steps to reproduce: 1) Open any page 2) Click on the little icon right before the url and drag it onto the Bookmarks menu/button in the Personal Toolbar 3) Keep the mouse button pressed until the text on the Bookmarks button turns red. 4) Release the button. Results: The bookmarks many opens and stays open. It is not possible to open any other menus or click any other buttons in the browser. If I do that, the bookmarks menu disappears for a fraction of second and then returns, it remains focused. Also, Mozilla grabs the mouse, and will not let me click on anything else on my desktop. Had to kill mozilla from console) Expected results: The bookmarks menu should close again, or not open at all ( bug 18052 is related to this, and marked as RFE ). Tested on: Linux Trunk 2001082121 Additional software: XFree86 4.10 KDE 2.2

Trying it the second time I was able to steal the mouse focus back from Mozilla and made a screenshot, and this exposes yet another problem. Instead of the bookmarks menu there some random garbage, part of it looks like a fragment of www.netscape.com I'm not sure if this should be filed as a separate bug.

While making the screenshot I saw the bookmarks menu as it shoud look, but the actual screenshot turned out like this. This one looks like an XFree bug.

I'm seeing this too in Mozilla Linux 2001082308. I use X 4.1 and PWM. Hiting Esc _and_ changing of virtual desktop "fixes" this (more or less, actually you'll see the drag icon still floating in the air).

->d&d

*** Bug 100071 has been marked as a duplicate of this bug. ***

blake, this sucks something aweful. I have to reboot my machine when this happens. Any chance you can fix it or disable the drop to bookmarks?

Linux is so lame. I don't really understand the problem. Why can't the menu be closed? How are menus normally closed in Linux? Yes, we could just disable bookmarks dropping on Linux, or I could change the menu opening and closing behavior on Linux if I understood what the problem was.

*** Bug 101112 has been marked as a duplicate of this bug. ***

*** Bug 106202 has been marked as a duplicate of this bug. ***

*** Bug 109721 has been marked as a duplicate of this bug. ***

*** Bug 104193 has been marked as a duplicate of this bug. ***

*** Bug 104793 has been marked as a duplicate of this bug. ***

*** Bug 111858 has been marked as a duplicate of this bug. ***

Clicking wildly around on the page seems to fix it for me (: maybe we could just call it a feature. [2001112308/linux]

*** Bug 108628 has been marked as a duplicate of this bug. ***

*** Bug 113033 has been marked as a duplicate of this bug. ***

*** Bug 113015 has been marked as a duplicate of this bug. ***

*** Bug 113169 has been marked as a duplicate of this bug. ***

*** Bug 113546 has been marked as a duplicate of this bug. ***

*** Bug 103252 has been marked as a duplicate of this bug. ***

*** Bug 114814 has been marked as a duplicate of this bug. ***

Blake, I noticed you just pushed out the target milestone again. If you can't fix the problem then please disable the feature. This bug makes the entire desktop unsable and (unless you're lucky and the 'click wildly' method actually works for you) the only way to get out of this mode is to log in to the machine remotely and kill the mozilla process or to power cycle the machine. 14 dups and counting

At least put on a "help wanted" and try to find some linux-UI-guys who know what's happening? If you can't fix this for 0.9.7 maybe it should go into "known problems", that would surly get some attention...and avoid more dupes.

*** Bug 115602 has been marked as a duplicate of this bug. ***

bug 113015 is still alive and healthy in Mozilla 0.9.7 (for Linux) unfortunately :(

*** Bug 117051 has been marked as a duplicate of this bug. ***

*** Bug 117653 has been marked as a duplicate of this bug. ***

*** Bug 117850 has been marked as a duplicate of this bug. ***

*** Bug 118218 has been marked as a duplicate of this bug. ***

*** Bug 118527 has been marked as a duplicate of this bug. ***

*** Bug 120861 has been marked as a duplicate of this bug. ***

cc'ing bryner & jag for insight, or reassignment. perhaps we should just disable for 0.9.8, and fix in 0.9.9?

My patch for draggable folders & cleanup fixes this.

Blake, Do you mean the patch of Bug #115764 ? I tried, it does not work for this. I think the problem is setting of timer in "nsWindow::OnDragMotionSignal", which causes the menu to popup endlessly. Stopping the timer will resolve the bug. It works for me. But in the current event flow, you can not drag something onto the bookmarks. The methods in nsWindow rely on gtk to deal with dragging events, but when the bookmarks menu popup, no event sent to gtk any longer. I think when the gtk are dragging, the menu should not grab the pointer again, to allow events forward to gtk_main_do_event instead of dispatch_superwin_event. I add a patch to fix these two problems ( see the previous entry ), it works. But I am not very sure other parts will not be affected. Someone review it?

blizzard: care to review?

No, I meant bug 106325, but my "fix" was just to disable it on linux. If you can get it working, great. Blizzard should review. -> boling

nominating

Bolian Could you please mark this bug as assigned and ask review? Jay

need r= sr=

pavlov, would you please review it

The best way to get review is by e-mailing blizzard@mozilla.org and ccing reviewers@mozilla.org, citing the bug number and asking for super review.

isn't this a dup of bug 84087?

R.K.Aa, that bug 84087 says the server hangs. This bug doesn't make it hang, just the menu won't close and focus is permanently stolen (requires me to switch out of X, and kill mozilla from cmdline) ...

Endico nominated this for mozilla1.0. Tagging it on her behalf.

*** Bug 128042 has been marked as a duplicate of this bug. ***

This is one of the top user visible and horribly painful linux bugs. It's got a several line patch awaiting review. adding mozilla1.0+ keyword.

The bug appears while dragging any link (like from the page in navigator window), not just the proxy icon. It's quite serious because even quick dragging over the bookmarks field triggers it, so you can't just "open link in chosen window" by dragging it from one window to another safely. Dragging some other links from the page often work better than random clicking, but it won't work in 100% and in some rare cases Mozilla will crash completely. Suggested workaround for now: Disable "bookmarks" in toolbar from preferences->navigator and use pull-down menu bookmarks instead.

*** Bug 133811 has been marked as a duplicate of this bug. ***

I'm seeing PT folder menus open on Win2k just by draggin the proxy icon over them using today's NS build. Is this the same problem?

This also happens with any folders in the personal tool bar (and not just the bookmark one). As soon as the dropdown menu opens, bam, you're screwed. :/ (2002032717 - Linux)

marking nsbeta1+. Bolian, will you be able to get to this in time for mozilla1.0? If not, I could try to find another owner.

I am sorry for the delay. I have submitted a patch, and asked for review serveral times. But no response. Peter, what should I do now? Ask for review another time and wait ?

You sent mail to blizzard@mozilla.org and cc'd reviewers@mozilla.org? Perhaps Chris is not available, you might try Syd or Pavlov or BRyner or...

The second part of this patch is incorrect: + // stop the endless setting and removing timer when the mouse pointer is not moving + return; That is done on purpose so if you drag to the bottom of a window drag events are generated and the window will scroll. I suspect, without running this patch, that will break that functionality.

Yes Blizzard, the timer will not break the functionality. The patch still can work with removing this line. The root reason is when bookmark menu popup, it grab the pointer from gtk who are doing the dragging. I have made new patches, add many new lines to make it work smoothly. I think it is better and more complete. I will paste the patches soon.

Oh, I can not obsolete the patch even I am the owner of patch and bug! I need to obsolete the patch and submit new ones. Who give me the right or help me do that.

Comment on attachment 67713 [details] [diff] [review] stop endless timeout, allow gtk to deal with dragging Setting obsolete. Ask asa@mozilla.org for extra Bugzilla permissions.

[Aside: bug#97729 has been fixed in Bugzilla CVS, and when b.m.o next updates, uploaders will be able to obsolete their own attchments.]

new patches submitted. need r=

also in solaris 7_8_9 2002040310 (has been a bug for a while)

*** Bug 135565 has been marked as a duplicate of this bug. ***

We're getting closer here. nsWindow::DragInProgress might as well be moved directly to the nsDragService class as a static method to see if there's a drag in progress. It's OK since it's inside the widget module and it's a whole lot faster than getting the service for every event when there's a grabbingWindow. The changes to handle_gdk_event make me nervous, but there may be no way to get around them. I need to think about that a little more. Anyway, as soon as I finish up bug 129591, this is going to be need to be changed as well. Also, the menu is never rolled up, even when the drop happens on the content area behind the menu. This leaves the menu up without a grab happening which can cause some interesting effects. What are the rules for how and when that meny is supposed to roll up?

> Also, the menu is never rolled up, even when the drop happens on the content area behind the menu. No, The menu CAN roll up, with mouse click as in Windows. Because when dragging I only disable "NativeGrab" but keep "sIsGrabbing = PR_TRUE; sGrabWindow = this;". Then in "handle_gdk_event" the nsWindow will take the event as normal. This seems to be HACK, but I have no other ways. The complex events flow is really a headache for me. > nsWindow::DragInProgress might as well be moved directly to the nsDragService That is better. Blizzard, bug 129591 has modified so many codes, should I make a new patch after its checkin? or you will do that?

*** Bug 135644 has been marked as a duplicate of this bug. ***

*** Bug 135768 has been marked as a duplicate of this bug. ***

Only want to confirm that this bug grabs the whole desktop, and that sometimes wild clicking gets one a usable desktop that allows to kill the Mozilla process. It takes considerable time to get there, if possible at all :( Build 2002040306, Linux

You can just switch to a console with Ctrl+Alt+F# and then kill mozilla from there. If it ever happens to me, I just press Esc and Ctrl+Q rapidly until Mozilla closes.

*** Bug 136372 has been marked as a duplicate of this bug. ***

*** Bug 136607 has been marked as a duplicate of this bug. ***

adt2

Bug 136607 encountered in Win2K - change OS to 'All'?

Unduping bug 136607, the issue reported in that bug is unrelated to this one.. Btw, I have been using this patch for one week in my tree and I encountered no regression so far.

*** Bug 136869 has been marked as a duplicate of this bug. ***

*** Bug 137423 has been marked as a duplicate of this bug. ***

*** Bug 137493 has been marked as a duplicate of this bug. ***

Hello, wrt, comment #69 I would like to add that this problem gets worse if one (like me) has a personal bookmarks taskbar and some folders in it - less space left for dragging the new URL to the sidebar pane w/o triggering the bug. Best, --Toni++

*** Bug 137939 has been marked as a duplicate of this bug. ***

I've been hit by this a couple of times, but on SPARC/SOLARIS (KDE 2.0.1 SunOS 5.8 sun4u and several mozilla builds this month). So I don't think it should be "Platform PC OS Linux". And as I don't know how to switch to a text-mode VT on Solaris to kill mozilla it's worse than a crash bug since I have to power-off the machine.

I think this might be a recursivity bug. Maybe it's better not to give he possibility to add the bookmarks menu to the the the toolbar, or put the Personal toolbar Folder in a saparate file ? Hmm the Bookmarks folder which contains the personal toolbar folder is contained in the personal toolbar ? Or am I mistaken ?

monchi: you're mistaken :-) The problems is with dragging ANY link and casually moving it across ANY subfolder of the toolbar folder (even if that wasn't where you wanted to drop it). Dragging from the url bar to the bookmarks folder is just an example, and it just happens to be the most common - not everybody has created subfolders on their personal toolbar.

I am having no problems whatsoever dragging and dropping any link to anything but the bookmarks itself. And in case someone wonders how to get out of the deadlock ( once it occurs ) just alternative press the escape key and press with the mouse on the page displayed by mozilla.. somehow this ends the deadlock.

Rapidly hitting escape and clicking sometimes works for me, but not always. If I remember not to release the mouse button when the folder opens unexpectedly but to just keep moving the mouse around, hitting escape once or twice is usually enough. Escape seems to mean "let the link drift back to where it came from", in this case out of the toolbar subfolder and back to the mouse! But other times it is more messy - I've attached an image in which one subfolder has grabbed the mouse from X and refuses to close, but Ive managed to open another at the same time, AND to work ksnapshot!

*** Bug 138100 has been marked as a duplicate of this bug. ***

*** Bug 138150 has been marked as a duplicate of this bug. ***

This bug just happened for me again (I get caught every couple of weeks or so, when I forget that D&D is not safe under Linux). This is a critical bug, not major. Criteria for critical is reproducable crash, as I understand it, and locking up the X server is actually worse than a crash in many ways. I've just voted for the bug, and hopefully 21 votes, X lockup and the fact that this bug has been around for 8 months will merit an increased priority and a pre-1.0 fix. I'd love to be able to recommend Mozilla/Linux to my semi-technical friends, but with this bug, I really cannot do that in good conscience. Not complaining really, just trying to poke the people who assign priorities so that the squeeky wheel can get some oil. Thanks for what is still the best browser available (short of telnet ;-) and good luck in tracking this puppy down!

I'll have this fixed one way or another before RC2. I need the event rewrite to land first.

This bud is still alive with Mozilla 1.0 Release Candidate 1 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 but. I am able to stop the loop by clicking couple times on offending menu, clicking couple times outside of offending menu.. There is NO NEED to go to console mode and KILL the beast (ooops mozilla)

*** Bug 138750 has been marked as a duplicate of this bug. ***

*** Bug 138782 has been marked as a duplicate of this bug. ***

*** Bug 138886 has been marked as a duplicate of this bug. ***

Adding dataloss keyword.

*** Bug 138901 has been marked as a duplicate of this bug. ***

this bug occurs whenever you drag the url icon across *any* of the personal menubar *folders*.

More generally, each folder you drag any URL over pops up and stays up. What is the dataloss scenario?

I reported 138886 because I end up in a perma-grab on GTK: I have to switch to a text console (if I can) or connect from a remote machine and kill Mozilla to recover my X session, losing whatever state is in Mozilla at the time (partially composed messages, form contents, etc.). I lost my bugzilla state twice filing the bug, because I'm a moron.

The times this happened to me I wound up power cycling my machine.

*** Bug 139341 has been marked as a duplicate of this bug. ***

So, what state is this bug in? Does it just need review, or should it be reassigned to blizzard?

I'm working on it.

*** Bug 139827 has been marked as a duplicate of this bug. ***

This bug has grown worst, it used to be limited to the bookmarks section of the personal toolbar. Now it does the same for all the personal toolbar folders.

The best way to test this bug without crashing your XWindows server is by starting mozilla in a nested server. In a terminal type the following ( in the same sequence ): /usr/bin/X11R6/Xnest :1 export DISPLAY=:1 (your window or desktop manager ) mozilla Now you can experiment without crashing your desktop X-server, only the independend nested server crashes.

Hello monchi, wrt your comment #104, I said something similar in #79 - can you confirm that earlier versions didn't have the problem with user defined bookmark folders in the personal toolbar? I was under the impression that the bug behaved always this way, just that I only recently started to add folders to my personal toolbar and thus had more chances to trigger it. Btw, your idea on running with nested X is nice! Thank you!

*** Bug 138126 has been marked as a duplicate of this bug. ***

a_geek ( is this correct ) ? Yes I have just confirmed that the user defined folders bug was not in 0.9.9, an d I am pretty shure It wasn.t in 0.9.8(7,6) in earlier versions it just sent the bookmark to /dev/null :). Monchi.

Re Comment #106, Comment #108: Indeed the bug does not occur for user defined folders in the Personal Toolbar in old Mozilla builds. Such folders did not autoopen upon hovering above them with a dragged bookmark until quite recently. The first build I have in which they do open (and do not want to close afterwards, i.e. the bug is present) is 2002032608.

*** Bug 140144 has been marked as a duplicate of this bug. ***

*** Bug 139722 has been marked as a duplicate of this bug. ***

*** Bug 140326 has been marked as a duplicate of this bug. ***

I seem to remember that in early versions of mozilla ( the m release series ) I used to have no problems whatsoever with inserting bookmarks anywhere on the personal toolbar folder.

*** Bug 140485 has been marked as a duplicate of this bug. ***

i found a way to re-gain the mouse/X control that is fast and works all the time (at least with me) press ESC and hold it try to drag the proxy icon (i usually only have to try 1-2 times to drag) as soon it drags, the problem is "fixed" and you have again control over the X/mouse again and the folder closes so people, stop killing mozilla, the X, restarting the OS, no need for that

*** Bug 140643 has been marked as a duplicate of this bug. ***

*** Bug 141018 has been marked as a duplicate of this bug. ***

*** Bug 141033 has been marked as a duplicate of this bug. ***

The patch that is in here still works, but it leaves folders open all over the place and gets things in such a state where you end up with folders just hanging on the screen without a grab. Plus, I've found out that there are real bugs in gtk that are longstanding and unfixed that will prevent drag and drop to windows that are created during a drag from receiving the drag events. This means that in real terms, I can't fix this bug. I really want to turn off the feature of dragging over folders automatically opens them but the DND-fu in the .js files is beyond my skills and my childish attempts to change the code hasn't been successful. I need help from the people who wrote and maintain the code to figure out how to turn this off for linux. We need to do this for the 1.0 timeframe because this is a really bad bug. I think that if we want to implement something like this, we could set it up so that you could drop a bookmark on a folder on the personal toolbar and it could pop up a window after the drop occurred and you could select where to put it. Didn't 4.x do it this way? I can't remember. Anyway, that's for another bug.

Chris, I have used the patch provided by Bolian in order to rewrite the way DND performs on the folders in the personal toolbar (bug 139471). I have also observed the problem you have reported: sometimes, when the menu opens, DND is lost. But I am pretty sure that this issue is not related to DND. In the personal toolbar, when I open a folder for the first time (no DND, just lclick), I got an assertion: ###!!! ASSERTION: The prototype binding has somehow lost its XBLDocInfo! Bad bad bad!!! : 'info', file nsXBLPrototypeBinding.cpp, line 365 ###!!! Break: at file nsXBLPrototypeBinding.cpp, line 365 Now, if I drag a link in this folder, menu opens cleanly, and DND performs in it as expected: this assertion is no more triggered, who knows why. If during DND, a folder is opened for the first time, the same assertion is triggered, and (imho) confuses DND, but won't if you try twice. I second disabling DND in folders for linux until the XBL assertion get fixed.

If you would like some advice from the peanut gallery and an ordinary Linux/Mozilla user. While draggin URLs directly into your bookmarks and personal folders is nice, IMHO you may freely disable this feature (and so protect 1.0 from this bug) ** so long as it remains possible to DND into the bookmarks pane of the sidebar. ** In fact, that's what I have been safely doing until RC1 was released. Now, as I drag the URL over the personal folders - while on my way to the sidebar - they pop-up and stay up, etc. Of course, it'd be nice if you can still give this bug your attention for 1.1.

I've found that double-clicking a couple times on the proxy icon in the location bar will get out of the lock condition by bringing up the Add Bookmark... window. Altho once or twice after triggering this bug I've noticed ghost DnD icons flying over the browser window when I'm not really paying attention. One just flew over this comment box. Kinda scary. =)

*** Bug 141291 has been marked as a duplicate of this bug. ***

*** Bug 141363 has been marked as a duplicate of this bug. ***

This bug (or one like it) exists in my Windows install, for folders on the personal toolbar, using RC1. I cannot remember having this problem with the .9.9 release. My workaround method is to click a bookmark in the open folder(s) to get folders to close. I sure hope this gets fixed before final 1.0 release.

*** Bug 141600 has been marked as a duplicate of this bug. ***

Re. comment 125: The Windows variant of this is bug 133601

*** Bug 141646 has been marked as a duplicate of this bug. ***

who can review this bug?

*** Bug 141944 has been marked as a duplicate of this bug. ***

At this point, I think it would be safer to just disable d&d for PT folders on Linux for beta, or at least stop them from popping open when dragging over. Could someone attach a patch for that?

An alternative way of regaining control: if you double-click, the second click goes to the window where you've clicked (as a single click). You can use it to get to the "File" menu and select "Close" (or "Quit"). If you chose "Close", the rest of Mozilla will start acting funny, so you have to save your work and restart it.

Adding Pierre to this bug, as his bug 139471 sounds like it is related to this one.

blizzard - can you r= this one?

Comment on attachment 82270 [details] [diff] [review] Per comment 131, disable popping open folders on the personal toolbar on unices for now. r=law

Samir, it seems like there was a lack of communication. Chris has marked this bug as dependent of bug 139471 because it already disables opening menu during DND for the Linux platform. bug 139471 largely encompasses this bug issue: it solves all the major DND problems in the personal toolbar and has also been added to the 138000 dependency list. Eventual issues with my patch could not be worse than the current behavior. Over to the drivers to decide which patch we should check in for RC2.

Comment on attachment 82270 [details] [diff] [review] Per comment 131, disable popping open folders on the personal toolbar on unices for now. sr=blizzard

At this point, I'll take the small fix for RC2. It doesn't mean that moving forward that the other bug can't be checked in after RC2, assuming that it fixes a good number of bugs.

Comment on attachment 82270 [details] [diff] [review] Per comment 131, disable popping open folders on the personal toolbar on unices for now. a=shaver for the branch.

agreed ... let's take the small fix on the branch. adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 brnach. Pls check this in today, then add the fixed1.0.0 keyword.

Checked in attachment 82270 [details] [diff] [review] on the branch.

samir says he checked attachment 82270 [details] [diff] [review] into the branch, so i am marking this fixed1.0.0. waiting for it to be checked into the trunk to resolve this one as fixed.

doh! my bad, what samir checked in wasn't a fix for this bug, but rather a small fix for disablinge the ability to pop open folders on the personal toolbar on unix. Removing fixed1.0.0 keyword.

Huh? That _was_ the fix for this bug.

I thought it was more of a temporary workaround, since we did want this feature to work everywhere.

Using linux branch build 2002050609, I can drag the url to the bookmarks folder on the personal toolbar but the bookmark is not added and the bookmark folder is not expanded

My bad, I have overlooked this simple patch: On Linux, onDragOver should bail return true instead of false so that onDrop can be triggered. trudelle: the implementation of this feature as it work on windows for the Linux platform is not possible (unless the pb is due to bug 141203), as chris pointed out. GTK does not handle correctly the menu opening during drag and drop. Chris suggested to implement the ns4 behavior: drop on the menu toolbar button, the menu opens and then select the place where to drop the item. This is not straightforward, neither because this would be a rewrite and imho should be postpone after moz1.0. I think we should all focus our attention on the tons of polish bugs that still remain on all platforms.

I must have smoked sth, forget what I wrote concerning samir's patch. Terry, the issue you are reporting is bug 135983, but it will be much more exposed for the linux platform. Should we disable drop in the bookmark button for RC2?

would an API like requested in bug 78248 help this bug? Dependency?

Pierre: I agree that we can live with the workaround for 1.0.

So this is not a mozilla bug but a library shortcomming ?

So this is not a mozilla bug but a library shortcomming ? If so why not circumvent the library, and write a new function ?

Pierre, do you need to fix this patch?

this is fixed on the branch.

Hmm tried it in the lates nightly build, but the bug has only worsened. Or is the fix not available in the nightly build ?

Chris: no, I don't need it. I was just asking drivers if this was needed for RC2. The fix for the branch is a two liner, I can provide it. Monchi: samir's patch has been checked in the branch, not the trunk. I hope that patch 139471 will be checked soon in the trunck

Pierre, I'm not exactly sure what isn't fixed here. What would a patch do for the branch do? What functionality is broken?

Is bug #143031 related to this?

*** Bug 143022 has been marked as a duplicate of this bug. ***

Verified fixed linux branch build 2002-05-08-10-1.0.0 but still a valid bug in trunk build 2002050809

This bug seems to have gotten worse (linux). On trunk and branch cvs builds, when clicking on the "Bookmarks" button on the personal toolbar, the bookmarks menu drops down, but then an icon of a piece of paper appears, and mozilla becomes unresponsive until hitting the esc key twice. Also, i don't know if this is related, but bookmarks fail to load in the sidebar on branch and trunk cvs builds (linux) This is true as of 1:52am eastern 5/10/02

That's not this bug. Please file a new one if it doesn't already exist, because we don't want to morph bugs.

Do you mean the former, the latter or both? I agree the latter (sidebar) is but the former I can't duplicate in linux build 2002050507 but I can with one from 20020510 which is after the patch for this appears to have gone in.

The first bug is bug #143031. A fix was checked in for that on the 1.0 branch last night. The latter bug is probably not related to this one.

*** Bug 143517 has been marked as a duplicate of this bug. ***

bug is fixed on RC2 Mozilla 1.0 Release Candidate 2 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510

marking this bug as "fixed" since the symptoms won't appear anymore, at least on linux. If the problem is still present on other platform, file a bug and assign it to me. Bolian: since I've used your patch to write the one in bug 139471, you must be credited. If you (or anybody else) are/is interested, you can try and solve the last issues on *nix platforms (real cause of bug 141031 and DND feedback being lost sometimes). To do so: - apply Bolian's patch - in navigatorDD.js, set isPlatFormNotSupported to false. DND in folders is working pretty well for linux in my tree.

comment 168: I'm confused. Which bug is the "make drag and drop onto bookmarks in Linux do something" bug for the trunk ? Currently the menu is not spring-loaded, which certainly fixes it, but at the cost of this feature. Thanks (and sorry for the spam).

should we open a new bug, to open this feature on trunk?

> should we open a new bug, to open this feature on trunk? sure, the issue is still alive behind the curtains! could you cc me please?

Verified fixed linux trunk build 2002060308 and linux branch build 2002060309

Bug #148996 is created to enable the drag and drop feature on Bookmark button.