Open Bug 38646 Opened 22 years ago Updated 12 years ago

mousedown on something draggable shouldn't give focus to mozilla

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

When you want to drag something from one app to another, you usually don't want 
the app you're dragging from to come to the front as soon as you start dragging 
(you don't NEED anything else visible .  

Windows Explorer fixes this by waiting until mouseup to switch focus when you 
click on some draggable things (such as files).  MS didn't do it completely 
correctly, however: mousedown on the icon in the "address" bar still brings 
that window to the front.  It would be really cool if mozilla did this "right".
NS 4.x does this "right", as far as I can tell.  Good point.
yup, and then the drag still fails.  changing severity to normal, assigning to 
saari as p3 for m18
Assignee: trudelle → saari
Severity: enhancement → normal
Target Milestone: --- → M18
removing RFE from summary
Summary: RFE: mousedown on something draggable shouldn't give focus to mozilla → mousedown on something draggable shouldn't give focus to mozilla
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
As far as I can tell, this doesn't work correctly with IE 5 for MacOS. 

Not sure if I'll be able to fix this... switching focus to mouseup, especially 
conditionally, is a fairly scary change. I'll think about it, and give it a try 
though.
Status: NEW → ASSIGNED
I haven't looked into the Windows code on this yet, but this sounds like 
it could be resolved on Windows by handling the WM_MOUSEACTIVATE message and 
returning WM_NOACTIVATE.
Not that easy, as the event sequence we care about really happens in XP code, and 
is fairly delicate.
Target Milestone: M21 → Future
Keywords: 4xp
OS: Windows 98 → All
Hardware: PC → All
As drag and drop comes back into the product more, this may be important. Would
be nice to fix for Mozilla 1.0
Target Milestone: Future → mozilla1.0
I think bug 51323 is a duplicate of this bug, or is dependent on this bug, or 
blocks this bug, or something.
I'd change that bug to be only the second part, and let this bug handle the 
first part.
Nominating nsdogfood, focus problems are high on the feedback list
Keywords: nsdogfood
*** Bug 88225 has been marked as a duplicate of this bug. ***
migrating keywords from dup
Blocks: 104166
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 126880 has been marked as a duplicate of this bug. ***
*** Bug 135590 has been marked as a duplicate of this bug. ***
This is not only a problem when interacting with other programs, but within
mozilla's windows: When dragging a link from the browser to the bookmarks
window, mozilla browser takes focus when clicking to the link. I believe
drag+drop shouldn't change window focus at all. This is the usual and most
practical thing to do.
bryner, switching focus to mouseup is something we should explore for the next
round of changes...
Assignee: saari → bryner
Status: ASSIGNED → NEW
That would be this code, right?

http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#1741

But we'd only want to not bring the window to the front until mouseup.  We still
need to focus text boxes, activate links, etc. on mousedown.
Links currently activate on mouseUP... This lets us grab them and drag them off
the window without activating them. Try it :)
Not for me.  When I mouse down on a link, it gets a focus rectangle and changes
to color (if defined).  The link isn't followed until mouseup, yes.
D'oh! I'm an idiot.

Sorry about that.
*** Bug 132678 has been marked as a duplicate of this bug. ***
*** Bug 180128 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.0.1 → Future
Target Milestone: Future → ---
*** Bug 260875 has been marked as a duplicate of this bug. ***
Does this bug include dragging an inactive tab in FF to a new position on the tab bar (which incorrectly activates the dragged tab instead of just moving it)?
No, that's bug 296970.
Assignee: bryner → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody
You need to log in before you can comment on or make changes to this bug.