38646 - mousedown on something draggable shouldn't give focus to mozilla

Status: NEW

(Core :: XUL, defect, P3)

Description

[Jesse Ruderman]

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

[:deanis74]

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

Comment 2

[Peter Trudelle]

yup, and then the drag still fails.  changing severity to normal, assigning to 
saari as p3 for m18

Comment 3

[Jesse Ruderman]

removing RFE from summary

Comment 4

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 5

[saari (gone)]

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.

Comment 6

[:deanis74]

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

[saari (gone)]

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

Comment 8

[saari (gone)]

As drag and drop comes back into the product more, this may be important. Would
be nice to fix for Mozilla 1.0

Comment 9

[Matthew T (active 1999-2002)]

I think bug 51323 is a duplicate of this bug, or is dependent on this bug, or 
blocks this bug, or something.

Comment 10

[:deanis74]

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

Comment 11

[selmer (gone)]

Nominating nsdogfood, focus problems are high on the feedback list

Comment 12

[Jesse Ruderman]

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

Comment 13

[Aaron Kaluszka]

migrating keywords from dup

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 126880 has been marked as a duplicate of this bug. ***

Comment 15

[Jesse Ruderman]

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

Comment 16

[Spiros Ioannou]

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

[saari (gone)]

bryner, switching focus to mouseup is something we should explore for the next
round of changes...

Comment 18

[:deanis74]

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

[Lewis Jardine]

Links currently activate on mouseUP... This lets us grab them and drag them off
the window without activating them. Try it :)

Comment 20

[:deanis74]

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

[Lewis Jardine]

D'oh! I'm an idiot.

Sorry about that.

Comment 22

[Jesse Ruderman]

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

Comment 23

[Jesse Ruderman]

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

Comment 24

[Vedran Miletic]

retargeting

Comment 25

[Tuukka Tolvanen (sp3000)]

*** Bug 260875 has been marked as a duplicate of this bug. ***

Comment 26

[Grick]

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

[Jesse Ruderman]

No, that's bug 296970.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 29

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.