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)
Core
XUL
Tracking
()
NEW
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".
Comment 1•25 years ago
|
||
NS 4.x does this "right", as far as I can tell. Good point.
Comment 2•24 years ago
|
||
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
Reporter | ||
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Comment 5•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
Not that easy, as the event sequence we care about really happens in XP code, and
is fairly delicate.
Updated•24 years ago
|
Target Milestone: M21 → Future
Updated•24 years ago
|
Comment 8•24 years ago
|
||
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
Comment 9•24 years ago
|
||
I think bug 51323 is a duplicate of this bug, or is dependent on this bug, or
blocks this bug, or something.
Comment 10•24 years ago
|
||
I'd change that bug to be only the second part, and let this bug handle the
first part.
Comment 11•24 years ago
|
||
Nominating nsdogfood, focus problems are high on the feedback list
Keywords: nsdogfood
Reporter | ||
Comment 12•23 years ago
|
||
*** Bug 88225 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 14•23 years ago
|
||
*** Bug 126880 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 15•22 years ago
|
||
*** Bug 135590 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
bryner, switching focus to mouseup is something we should explore for the next
round of changes...
Assignee: saari → bryner
Status: ASSIGNED → NEW
Comment 18•22 years ago
|
||
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.
Comment 19•22 years ago
|
||
Links currently activate on mouseUP... This lets us grab them and drag them off
the window without activating them. Try it :)
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
D'oh! I'm an idiot.
Sorry about that.
Reporter | ||
Comment 22•21 years ago
|
||
*** Bug 132678 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 23•21 years ago
|
||
*** Bug 180128 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
*** Bug 260875 has been marked as a duplicate of this bug. ***
Comment 26•19 years ago
|
||
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)?
Reporter | ||
Comment 27•19 years ago
|
||
No, that's bug 296970.
Updated•18 years ago
|
Assignee: bryner → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•16 years ago
|
Assignee: jag → nobody
Updated•2 years ago
|
Severity: normal → S3
Comment 28•2 years ago
|
||
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)
Comment 29•2 years ago
|
||
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.
Description
•