288775 - dragging on maps.google.com doesn't work for very long

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 1

[R.K.Aa.]

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". 

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It may be relevant that I have the "general.smoothScroll" pref set to true.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's also possible this could have been caused by bug 286813.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, I was right the first time.  I confirmed by backout that this was
caused by bug 284664.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The working build fires the same mouseout events with the same target parameter
to HandleDOMEvent. There must be some difference further down the line.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 179882 [details] [diff] [review]
fix

r+sr=bzbarsky

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 179882 [details] [diff] [review]
fix

High visibility regression, simple fix.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.)

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2005-04-18-05 on Windows XP, Seamonkey trunk.