Closed Bug 96504 Opened 23 years ago Closed 22 years ago

after dragging proxy icon onto bookmarks button, bookmarks menu refuses to close

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: duke, Assigned: yinbolian)

References

Details

(Keywords: dataloss, Whiteboard: [adt2 rtm])

Attachments

(5 files, 1 obsolete file)

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
Attached image attaching a screenshot —
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
->d&d
Assignee: asa → blakeross
Component: Browser-General → XP Apps: Drag and Drop
QA Contact: doronr → tpreston
Summary: dragging a link from location bar onto bookmarks button renders the browser unusable → after dragging proxy icon onto bookmarks button, bookmarks menu refuses to close
*** 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?
Blocks: 101793
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. ***
Target Milestone: --- → mozilla0.9.7
*** 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. ***
Attached image Another screenshot —
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. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
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.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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
Assignee: blaker → bolian.yin
Target Milestone: mozilla0.9.9 → ---
nominating
Keywords: nsbeta1
Bolian
Could you please mark this bug as assigned and ask review?
Jay
need r= sr=
Status: NEW → ASSIGNED
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.
Keywords: mozilla1.0
*** Bug 128042 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: --- → mozilla1.0
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.
Keywords: mozilla1.0mozilla1.0+
Whiteboard: need r=
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.

Blocks: 133604
*** 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.
Keywords: nsbeta1nsbeta1+
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.
Attachment #67713 - Attachment is obsolete: true
[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
Whiteboard: need r= → need r= [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.
Blocks: 138000
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.
Keywords: dataloss
*** 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.
Depends on: 139471
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. ***
Whiteboard: need r= [adt2] → need r= [adt2] [M5+]
who can review this bug?
Whiteboard: need r= [adt2] [M5+] → [need r=] [adt2] [M5+]
*** 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
Attachment #82270 - Flags: review+
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
Attachment #82270 - Flags: superreview+
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.
Attachment #82270 - Flags: approval+
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.
Keywords: adt1.0.0+
Whiteboard: [need r=] [adt2] [M5+] → [adt2] [M5+]
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.
Keywords: fixed1.0.0
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.
Keywords: fixed1.0.0
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?
Whiteboard: [adt2] [M5+] → [adt2]
this is fixed on the branch.
Keywords: fixed1.0.0
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
Keywords: verified1.0.0
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
Whiteboard: [adt2] → [adt2 rtm]
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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Bug #148996 is created to enable the drag and drop feature on Bookmark button.
You need to log in before you can comment on or make changes to this bug.