fire the onDragOver even repeatedly when doing a drag (and the mouse is not moving). windows and gtk2 already do this, and for scrolling tabs, we'd need this, or we'd need to work around it in the toolkit for mac. to see where it is needed, see bug #318168 (and the patch in the bug) drag a tab (or a url) and hold it over the arrowscrollbox. the desired effect is that we scroll even if the mouse is not moving. mark and I were concerned that changing the widget code for mac may cause regressions. I'm less worried about calling onDragOver frequently (unless someone out there has hacked their code to work around this mac issue) and more worried about performance issues.

in bug #341830, I wrote: for mac, onDragOver is not being called repeatedly when the mouse isn't moving, as it does on windows. From an ancient post from pink (http://groups.google.com/group/netscape.public.mozilla.mac/browse_thread/thread/6cd00f8ae7b6e07a/192a62a1599f0bc1) Here's how Mac D&D is working so far: - each window (mac window) registers a tracking handler and a receive handler with the drag manager - the tracking handler gets called when the mouse enters/leaves the window and when the mouse moves within the window. - the receive handler gets called when a drop over a window occurs. mark suggested that I might need a timer to solve this problem, but I wanted to ping pink and see if I'm on the right track.

IIRC, the drag manager is synchronous, so timers that rely on an event loop may not fire. That certainly was the case on os9, i'm not sure if that's still the case on osx with carbon Events.

This was assigned to me for a reason: I told Seth I'd fix it in exchange for food.

Oops, sorry. I didn't mean to re-assign, my muscle-memory made me do it.

Re comment 2, I know exactly what pink means about the classic system, but I know for sure that I can fix this with a Carbon timer. Since, according to Seth, the win32 and gtk widget libraries send NS_DRAGDROP_OVER repeatedly even when the mouse isn't moving, I agreed to make the Mac (Carbon) widget library conform in the interest of platform parity. We'll also need to do the same thing for Cocoa.

I developed this on the 1.8[.1] branch because there seems to be a bug on the trunk preventing NS_DRAGDROP_OVER events from having any effect.

mark's patch works for me on mac 10.4 / 1.8 branch with my patch for #318168

+ ::InstallEventLoopTimer(::GetMainEventLoop(), I would usually use ::GetCurrentEventLoop() here, and will change this.

Checked in on trunk.

Comment on attachment 226564 [details] [diff] [review] Patch Requesting approval1.8.1. This is a longstanding platform parity issue, and is needed to support bug 318168 properly on the Mac.

Checked in on MOZILLA_1_8_BRANCH for 1.8.1b1.