mousedown on something draggable shouldn't give focus to mozilla




18 years ago
8 years ago


(Reporter: Jesse Ruderman, Unassigned)



Firefox Tracking Flags

(Not tracked)




18 years ago
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

18 years ago
NS 4.x does this "right", as far as I can tell.  Good point.

Comment 2

18 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

Comment 3

18 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

18 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Comment 5

18 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 

Comment 6

18 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

18 years ago
Not that easy, as the event sequence we care about really happens in XP code, and 
is fairly delicate.


18 years ago
Target Milestone: M21 → Future


18 years ago
Keywords: 4xp
OS: Windows 98 → All
Hardware: PC → All

Comment 8

18 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

18 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

18 years ago
I'd change that bug to be only the second part, and let this bug handle the 
first part.

Comment 11

17 years ago
Nominating nsdogfood, focus problems are high on the feedback list
Keywords: nsdogfood

Comment 12

17 years ago
*** Bug 88225 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
migrating keywords from dup
Keywords: correctness, mozilla0.9.3, nsbeta1


17 years ago
Blocks: 104166


17 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 126880 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
*** Bug 135590 has been marked as a duplicate of this bug. ***

Comment 16

15 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

15 years ago
bryner, switching focus to mouseup is something we should explore for the next
round of changes...
Assignee: saari → bryner

Comment 18

15 years ago
That would be this code, right?

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

15 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

15 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

15 years ago
D'oh! I'm an idiot.

Sorry about that.

Comment 22

15 years ago
*** Bug 132678 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
*** Bug 180128 has been marked as a duplicate of this bug. ***

Comment 24

15 years ago
Target Milestone: mozilla1.0.1 → Future


15 years ago
Target Milestone: Future → ---
*** Bug 260875 has been marked as a duplicate of this bug. ***

Comment 26

12 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)?

Comment 27

12 years ago
No, that's bug 296970.
Assignee: bryner → jag
QA Contact: jrgmorrison → xptoolkit.widgets


9 years ago
Assignee: jag → nobody
You need to log in before you can comment on or make changes to this bug.