Dragging on http://maps.google.com/ , which is supposed to move the map around, regressed between 2005-03-28-09-trunk and 2005-03-29-10-trunk (Linux builds). Steps to reproduce: 1. load http://maps.google.com/ 2. depress the left mouse button somewhere over the map 3. while the mouse button is pressed, drag the mouse in large circles, staying over the map area Expected results: 3. Map moves corresponding to mouse drag Actual results: 3. Map stops moving shortly after drag starts, probably because a new image loa starts. My initial guess at the cause of the regression is bug 284664 (checked in 2005-03-28 15:39 -0800).
Happens on winXP too: A quick drag loses the grip almost instantly. But if i drag *very* slowly it seems i can go on dragging "forever".
It may be relevant that I have the "general.smoothScroll" pref set to true.
It's also possible this could have been caused by bug 286813.
Actually, I was right the first time. I confirmed by backout that this was caused by bug 284664.
Map movement stops when we fire a mouseout event, so I don't think it's connected to image loads or anything like that. I'll have to experiment to see if older builds didn't fire mouseout at all, or used a different target, or what.
The working build fires the same mouseout events with the same target parameter to HandleDOMEvent. There must be some difference further down the line.
Created attachment 179882 [details] [diff] [review] fix The problem is that we aren't passing the 'related target' to the mouseout event anymore (which indicates which element is being moved into). This patch fixes that, it's very simple.
Comment on attachment 179882 [details] [diff] [review] fix r+sr=bzbarsky
Comment on attachment 179882 [details] [diff] [review] fix High visibility regression, simple fix.
Comment on attachment 179882 [details] [diff] [review] fix a=dbaron if you're sure you're never passing content across documents (which could have security implications, perhaps)
Good thought. The only caller of NotifyMouseOut with non-null aMovingInto is from NotifyMouseOver in the same document/ESM, which immediately dispatches a mouseover to the same content, so we're not adding any new exposure. (And just for kicks, I checked that the callers of NotifyMouseOver do ensure that aContent is in the ESM's document, unless ESM::GetEventTargetContent can return content from a different document, in which case we have some large existing bug. Actually we should probably add an assertion about that.)
Verified FIXED using build 2005-04-18-05 on Windows XP, Seamonkey trunk.