Closed
Bug 572294
Opened 14 years ago
Closed 14 years ago
when creating a drop event make sure the refpoint is relative to the widget we actually use
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Core
DOM: Copy & Paste and Drag & Drop
Tracking
()
RESOLVED
FIXED
People
(Reporter: tnikkel, Assigned: tnikkel)
Details
Attachments
(1 file, 1 obsolete file)
2.40 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
When we create a drop event based on an existing mouse event there is the potential that we use a different widget than the existing mouse event. So adjust the refpoint. I figured this was safer than switching to use the same widget as the mouse event. I also noticed some comments above GenerateDragGesture don't seem to be valid anymore. As far as I can tell that code correctly deals with the mentioned cases now.
Attachment #451497 -
Flags: review?(enndeakin)
Updated•14 years ago
|
Component: DOM: Events → Drag and Drop
QA Contact: events → drag-drop
Comment 1•14 years ago
|
||
Seems ok, but roc would be a better reviewer
Assignee | ||
Updated•14 years ago
|
Attachment #451497 -
Flags: review?(enndeakin) → review?(roc)
Assignee | ||
Comment 2•14 years ago
|
||
DOM created events have no widget, but they set the refpoint to the screenpoint. So handle the null widget case.
Attachment #451497 -
Attachment is obsolete: true
Attachment #451731 -
Flags: review?(roc)
Attachment #451497 -
Flags: review?(roc)
How can mouseEvent->widget be null? Surely it can't? Can we just assert it's not null and crash if it is?
Assignee | ||
Comment 4•14 years ago
|
||
When the drop event created here http://mxr.mozilla.org/mozilla-central/source/content/events/test/test_bug508479.html?force=1#57 gets to the code in the patch the mouse event has no widget and we crash with v1 of the patch.
How about, if the event has no widget we assert that the refpoint is 0,0 (since it's meaningless) and set our refpoint to (0,0) as well? Or something like that?
Assignee | ||
Comment 6•14 years ago
|
||
In the case I mentioned the refPoint gets set to (screenX, screenY) as passed to the initDragEvent function.
Comment on attachment 451731 [details] [diff] [review] patch v2 ok, can you make sure it's documented somewhere that a null widget means refpoint is in screen coordinates?
Attachment #451731 -
Flags: review?(roc) → review+
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #7) > ok, can you make sure it's documented somewhere that a null widget means > refpoint is in screen coordinates? Neil, do you know if that is documented somewhere? Or where I should document it?
Comment 9•14 years ago
|
||
I believe it is document only in the code, in nsDOMMouseEvent::InitMouseEvent
Assignee | ||
Comment 10•14 years ago
|
||
I think a good place for it would be in nsGUIEvent.h in the definition of nsEvent where we define the refPoint. // In widget relative coordinates, not modified by layout code. nsIntPoint refPoint; I'll change it to: // Relative to the widget of the event, or if there is no widget then it is // in screen coordinates. Not modified by layout code.
Assignee | ||
Comment 11•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/4f1ae85ff9d1
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•