Closed
Bug 288775
Opened 19 years ago
Closed 19 years ago
dragging on maps.google.com doesn't work for very long
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: dbaron, Assigned: roc)
References
()
Details
Attachments
(1 file)
6.50 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
dbaron
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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•19 years ago
|
Flags: blocking1.8b2?
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•19 years ago
|
||
It may be relevant that I have the "general.smoothScroll" pref set to true.
Reporter | ||
Comment 3•19 years ago
|
||
It's also possible this could have been caused by bug 286813.
Reporter | ||
Comment 4•19 years ago
|
||
Actually, I was right the first time. I confirmed by backout that this was caused by bug 284664.
Assignee | ||
Comment 5•19 years ago
|
||
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.
Assignee | ||
Comment 6•19 years ago
|
||
The working build fires the same mouseout events with the same target parameter to HandleDOMEvent. There must be some difference further down the line.
Assignee | ||
Comment 7•19 years ago
|
||
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 8•19 years ago
|
||
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+
Assignee | ||
Comment 9•19 years ago
|
||
Comment on attachment 179882 [details] [diff] [review] fix High visibility regression, simple fix.
Attachment #179882 -
Flags: approval1.8b2?
Reporter | ||
Comment 10•19 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+
Assignee | ||
Comment 11•19 years ago
|
||
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.)
Assignee | ||
Comment 12•19 years ago
|
||
checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: blocking1.8b2?
Verified FIXED using build 2005-04-18-05 on Windows XP, Seamonkey trunk.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•