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

VERIFIED FIXED

Status

()

Core
Event Handling
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: dbaron, Assigned: roc)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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).
(Reporter)

Updated

13 years ago
Flags: blocking1.8b2?

Comment 1

13 years ago
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". 
(Reporter)

Comment 2

13 years ago
It may be relevant that I have the "general.smoothScroll" pref set to true.
(Reporter)

Comment 3

13 years ago
It's also possible this could have been caused by bug 286813.
(Reporter)

Comment 4

13 years ago
Actually, I was right the first time.  I confirmed by backout that this was
caused by bug 284664.
(Reporter)

Updated

13 years ago
Blocks: 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.
Assignee: events → roc
Status: NEW → ASSIGNED
Attachment #179882 - Flags: superreview?(bzbarsky)
Attachment #179882 - Flags: review?(bzbarsky)
Comment on attachment 179882 [details] [diff] [review]
fix

r+sr=bzbarsky
Attachment #179882 - Flags: superreview?(bzbarsky)
Attachment #179882 - Flags: superreview+
Attachment #179882 - Flags: review?(bzbarsky)
Attachment #179882 - Flags: review+
Comment on attachment 179882 [details] [diff] [review]
fix

High visibility regression, simple fix.
Attachment #179882 - Flags: approval1.8b2?
(Reporter)

Comment 10

13 years ago
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)
Attachment #179882 - Flags: approval1.8b2? → approval1.8b2+
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.)
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Flags: blocking1.8b2?
Verified FIXED using build 2005-04-18-05 on Windows XP, Seamonkey trunk.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.