Open Bug 38646 Opened 25 years ago Updated 2 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
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.