Closed Bug 143031 Opened 23 years ago Closed 23 years ago

opening the bookmarks item on the personal toolbar starts a drag on linux and Sun

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: blizzard, Assigned: p_ch)

References

Details

(Keywords: qawanted, Whiteboard: qawanted for *nix and other platforms)

Attachments

(3 files)

If I open the 'Bookmarks' item on my personal toolbar and start to move the mouse down over the items in that new popup a drag is started. Oops! You also can't get rid of the drag as near as I can tell.
Blocks: 138000
Sounds like bug 143029 (reported nine minutes earlier...)?
*** Bug 143029 has been marked as a duplicate of this bug. ***
Yeah, but this has more people on it and it's already marked as dup.
*** Bug 142821 has been marked as a duplicate of this bug. ***
Seeing the problem with Solaris 8/9/etc... This is really irritating since it makes the browser unusable once the drop marker is posted. It effectively has permanent focus from the window manager and you can barely click on any other window to even kill the mozilla process. This is 100% reproduceable in the nightly CVS builds that we do within Sun. This problem only started happening since 20020505 (4th or 5th May) builds onwards, so we should easily be able to track it down.
Forgot to add, that this doesn't appear to a window manager bug since i can reproduce it on the WindowMaker, CDE, and GNOME (sawfish) window managers.
Is this related to the fix for bug 96504?
This is unrelated with bug 96504 since build 2002-05-06-15 has the patch and is ok. The regression occurred between: build 2002-05-07-09 and build 2002-05-08-10 This leads to the following checkins: http://bonsai.mozilla.org/cvsquery.cgi?module=SeaMonkeyAll&branch=MOZILLA_1_0_0_BRANCH&hours=2&date=explicit&mindate=05%2F07%2F2002+09%3A00&maxdate=05%2F08%2F2002+10%3A00
(builds from the branch)
*** Bug 143009 has been marked as a duplicate of this bug. ***
Attached patch patch (deleted) — Splinter Review
Patch that makes sure that drags don't start on unix.
I can confirm that patch 82887 (attached) fixes the problem on Solaris (probably all platforms since there is no architecture dependent code here). Ok to close once it is integrated in the cvs tree. This may be a different issue, but we also appear to have lost the ability to drag a URL from the location field and drop onto the personal toolbar. I'm sure this used to work before. Can anyone confirm that this behavior has suddenly disappeared ? Actually this is not related to the posted patch since the drag appears to work, but the toolbar is not accepting drops anymore...
Actually, this is not entirely fixed. Try dragging from the location entry icon in the Navigation toolbar to the "Bookmarks" pulldown on the personal toolbar and the drop sticks as before, rendering the browser unuseable.
*** Bug 143227 has been marked as a duplicate of this bug. ***
Attached patch patch (deleted) — Splinter Review
Chris, your patch "fixes" the draggesture problem because it throws an javascript exception: event is not passed in CheckDragGesture. Also, nsDragAndDrop.startDrag was called for the X11 platform, therefore, it was preventing also drag for the other platforms. I attached another patch for the branch that prevents draggestures in the bookmark button from bubbling to the toolbar. Drag and drop is still possible in the PT. This patch, like the previous one, only fixes the symptoms, not the real bug. Dave... bug 96504 is fixed on the branch only!!!
Seems good enough to me, although I have to defend my patch saying that I never saw the drag happen on my platform and I never saw an exception. But maybe I just missed it. Anyway, someone with stronger xul-fu should review that patch.
Pierre, does bug 139471 patch fix this problem?
Keywords: nsbeta1
*** Bug 143247 has been marked as a duplicate of this bug. ***
Asa: sorry for the delay, I had to update my tree and figure out how to work around bug 142853 (grr...). I tried to confirm this bug with and without my patch on the trunk, and although I would have bet that my patch does not fix this weirdness, I had to convince myself that it does, indeed. Don't ask me why! :) I'll update the patch in bug 142853 per timeless review, right now. I am pulling the branch, now. I will test if the bug disappears, too. But it will take a lot of time.
Keywords: nsbeta1
Pierre, I think we're going to go with another bandaid here and try for your http://bugzilla.mozilla.org/showattachment.cgi?attach_id=82916 patch.
Asa, I agree we should not put the patch in bug 139471 for RC2. I am just checking what happens in the branch with this patch, looking forward at the next branch release.
Comment on attachment 82916 [details] [diff] [review] patch sr=blizzard
Attachment #82916 - Flags: superreview+
Piere, how about removing the check for X11? There's no reason to drag the bookmarks menu around, and it has the added benefit that you can click-drag the menu open (so you press the left mouse button on the menu, drag your mouse down and release it on the bookmark you want).
Since there seems to be some confusion about what I'm really asking here, let me make it a little more clear: Can/should we call preventBubble for all platforms instead of just for X11?
I don't know if we want to remove that functionality or not, but we know that it breaks linux pretty badly. Can we talk about removing the functionality some other time and just get this in for RC2?
sr=jag for rc2 (not trunk).
Comment on attachment 82916 [details] [diff] [review] patch a=rjesup@wgate.com for drivers as per Asa
Attachment #82916 - Flags: approval+
Fix checked into branch as per Asa's request. Not closing because there are still other issues to discuss/fix here for trunk.
Keywords: fixed1.0.0
*** Bug 143439 has been marked as a duplicate of this bug. ***
Jag: your approach is more correct, we must be careful at event bubbling thought, since menu/menuitem startdrag bubble throught it. I have implemented your approach in bug 139471. However, the user will not notice the change, since container drag is prevented on all platforms. But when we will relax it, we will hit this issue again.
Assignee: blaker → pierrechanial
*** Bug 143639 has been marked as a duplicate of this bug. ***
BUILD ID: 2002051010 I've got two crashes after clicking on the bookmark link at the personal toolbar: TB6168782Y TB6169524K
Not sure if this is the same bug but please Confirm or not Confirm if that is a different one. Since today 11th May Whenever I enter the Bookmarks menu on the Personal Toolbar I completley loose the focus, the mouse pointer is changed (as described) into the drag mouse pointer. If I click additional then on Manage Bookmarks the Bookmark Menu doesn't go away. This is even so bad that I have to kill mozilla on the console as the whole focus for the complete WindowManager is up to Mozilla. This happened on both Gnome and in IceWM. I attached a screenshot (NOTE: I had to repaint the Mousepointer in GIMP because it was hidden by the screenshot program) This does *not* occur when I go to the Bookmarks Main Menu
Attached image Horked Bookmarks (deleted) —
Carsten, yes, this sounds like the same bug. Also related is bug 96504, which I believe has been "fixed" by disabling the facility on Linux. How the original feature ever landed I don't understand :(
*** Bug 143885 has been marked as a duplicate of this bug. ***
If you are trapped inside of the bookmarks menu, you can get back to the normal by pressing ESC twice. This prevents from having to kill mozilla from the console.
*** Bug 144046 has been marked as a duplicate of this bug. ***
*** Bug 144096 has been marked as a duplicate of this bug. ***
I don't see why this bug is not marked a blocker, since it makes Mozilla completely unusable. So the fix should be checked into the trunk, even if it will be improved later (as comment 29 says). pi
Just to let you all know that people still care about this bug :-) And (more importantly) to help in weeding out the unneeded duplicates. Here are my candidates to be marked as a duplicate of this bug: bug 143785 bug 144251 bug 144267 bug 143479(?)
*** Bug 144267 has been marked as a duplicate of this bug. ***
*** Bug 143785 has been marked as a duplicate of this bug. ***
*** Bug 144251 has been marked as a duplicate of this bug. ***
*** Bug 143479 has been marked as a duplicate of this bug. ***
*** Bug 144973 has been marked as a duplicate of this bug. ***
*** Bug 145314 has been marked as a duplicate of this bug. ***
Applying the patch to the trunk sources, i.e. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020522, solves the problem in Linux. I still think the trunk should not stay unpatched any longer. Or did the problem vanish for other reasons? There are no recent dupes to my surprise. An observation from Windows trunk builds (unpatched): I use to press "Bookmars" and move the mouse down keeping the left button pressed. This causes a problem, Mozilla behaves as dragging a bookmark. Is this the same bug? pi
mrmazda: the current bug is unrelated. This one is due to a mouse up event (that should prevent DND) not fired when a menupopup opens while the other one seems to be caused by a particulat bookmark file. boris: a pach exists in bug 139471 that masks the problem on linux and fixes the issue you raised on Windows. Fyi, these issues are unrelated. I would be grateful is you would have time to test (on linux and windows) the last version of the patch in bug 139471 and bug 145350 and report your findings to accelerate the review process.
Depends on: 139471
I reported this about a week ago: http://bugzilla.mozilla.org/show_bug.cgi?id=144274 I think it may be duplicate, and the comments say so but for some reason it has not been marked as such. This is on Mac OS X.
Boris, try making this change on your build from the trunk: --- xpfe/browser/resources/content/navigator.xul Thu May 9 16:13:43 2002 +++ xpfe/browser/resources/content/navigator.xul Thu May 9 16:14:05 2002 @@ -258,6 +258,7 @@ datasources="rdf:bookmarks rdf:files rdf:localsearch rdf:internetsearch" ref="NC:BookmarksRoot" container="true" flags="dont-test-empty" oncommand="OpenBookmarkURL(event.target,document.getElementById('BookmarksMenu').database)" + ondraggesture="event.preventBubble();" ondragover="nsDragAndDrop.dragOver(event, folderObserver);" template="bookmarksMenuTemplate"> <menupopup onpopuphiding="gDidOpen = false;"
I've accidently found a way to unwedge the menu (under Linux). This doesn't fix the bug, but lets you get rid of the menu without killing mozilla or quitting X. Press in 'ALT-<LETTER>' where LETTER is the first letter of some submenu of the bookmark menu. This causes the submenu to open... Then if you futz with the mouse a little. (I don't recall the exact fuddlings.) you can get the bookmark menu to close, unwedging it. Then, you can continue as normal. This isn't a fix, but it at least it unwedges mozilla to make it easier to continue development/using it. (Also, can someone mark 146103 as a dup of this?)
*** Bug 146103 has been marked as a duplicate of this bug. ***
*** Bug 146254 has been marked as a duplicate of this bug. ***
jag, your fix works for my windows problem. Thanks also for the personal support by e-mail. Next I gonna check out Pierre's patches. As he pointed out this (win) problem is unrelated, but his patch will take care of both items. I'll be back on this. pi
Comment 51 checked in Win98SE. Fixes my win problem. Also thanks for extended support. pi
just thought I'd report that the bug still exists in build 2002052307
*** Bug 146501 has been marked as a duplicate of this bug. ***
Same problem on Sun/Solaris with any nightly build most recent than 20020502. It makes Mozilla unusable !
Unusable? whilst its a MAJOR pain in the rear if you forget and go for the toolbar button there is a workaround... Use the bookmarks menu item instead. This bug only shows up for me (on solaris 8 sparc platform) with the toolbar button.
And in any case you should know that the Bookmarks item is removable. In the preferences/navigator menu the lower third of the page has a radio button to deselect it.
The patches named in comment 51 work under Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020527. pi
*** Bug 146759 has been marked as a duplicate of this bug. ***
Summary: opening the bookmarks item on the personal toolbar starts a drag on linux → opening the bookmarks item on the personal toolbar starts a drag on linux and Sun
*** Bug 147700 has been marked as a duplicate of this bug. ***
Having this problem on Linux with today's build. This problem did not appear in the RC3 release for me, but is consistantly reproduceable with today's build.
I'm also still seeing this problem, with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020530
This problem disappeared with build 2002052921 for me. The build I was using yesterday when I noted the problem was 2002052908.
I'm still seeing it on this morning's trunk build (2002053008). I got so tired of this bug I removed the Bookmarks menu from the toolbar a couple of days ago (Edit -> Preferences -> Navigator, uncheck Bookmarks in the "Select the buttons you want to see in the toolbars"). This gives me more room in my personal toolbar folder and I can still get to all of my bookmarks just fine through the Menu Bar. I actually consider this bug a feature now... ;)
fixed on trunk by the checkin of bug 139471. Thought, the fact that mouse up are eaten when any menupopup opens on mouse down still remains. The fix only mask it.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
qawanted for platforms other than linux, mac and windows. If the problem is still not fixed on a platform, then open a new bug report and assign it to me. I strongly suspect that for SUN, the problem still exists, but it's a one liner fix.
Keywords: qawanted
Whiteboard: qawanted for *nix and other platforms
Pierre: Is there a bug for the item you tell is still not resolved in comment #71? If there is, please give us a bug number, if there isn't, please file one - it seems you know better about that issue than e.g. me...
*** Bug 148325 has been marked as a duplicate of this bug. ***
Confirm appears fixed on Solaris with nightly build 2002053023. Previously expected behaviour is restored with both <click-and-hold><slide-to-bookmark><release> and <click-and-release><second-click-on-bookmark> resulting in opening the bookmarked page.
Verified fixed linux trunk build 2002060308 and branch build 2002060309
Status: RESOLVED → VERIFIED
*** Bug 148028 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: