Closed
Bug 481737
Opened 16 years ago
Closed 13 years ago
ondragleave and ondragexit not getting called when dragging out of one presentation shell into another
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: erik.staats, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [fixed in bug 591249])
Attachments
(1 file)
613 bytes,
application/x-gzip
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
This bug occurs when multiple presentation shells are present in the application, such as browser1 containing browser2. If a drag session is started and the mouse is moved into browser2, dragleave and dragexit events are sent to elements within browser2 as long as the mouse stays in browser2.
If the mouse is moved out of browser2 into the enclosing browser1, dragleave and dragexit events are not sent to elements in browser2.
Reproducible: Always
Steps to Reproduce:
1. Launch Firefox 3.0.6 or Minefield 3.2a1pre 20090305 from a console.
2. Set browser.dom.window.dump.enabled pref to true.
3. Open the test1.xul file from the bug attachment.
4. Select some text and drag it into the test2 box displayed in test1.xul.
5. Drag the text down outside of the test2 box.
6. Drag the text back into the test2 box.
7. Drag the text up out of the test2 box.
Actual Results:
In step 5, "leave2" and "exit2" are displayed on the console. In step 7, they are not. Also, "leave2" and "exit2" are displayed when entering the test2 box.
Expected Results:
In step 7, "leave2" and "exit2" are displayed on the console.
PresShell::HandleEvent must send the drag exit event to the presentation shell containing the previous mouse coordinates. However, it sends all events, including drag exit, to the presentation shell containing the current mouse coordinates.
The state required to route the event to the proper location is maintained in nsEventStateManager objects. Each presentation shell has its own nsEventStateManager object. Thus, by sending the drag exit event to the wrong presentation shell, the wrong state is used and the event does not get to the proper element.
Interestingly, mouseout events do get sent to the proper location.
Due to this bug, :-moz-drag-over styling does not work properly and the styling will not be removed in the cases where the dragexit event does not fire properly. Note that the drag over styling of the boxes will not work at all in Minefield due to bug 481727.
Reporter | ||
Comment 1•16 years ago
|
||
Updated•16 years ago
|
Component: General → Event Handling
Product: Firefox → Core
QA Contact: general → events
Comment 2•16 years ago
|
||
I think I've seen this myself with FF3.1b2 builds, but I hesitate to confirm it because I don't have my testcase handy (and yours is zipped up).
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•14 years ago
|
OS: Mac OS X → All
Comment 3•14 years ago
|
||
This is why we don't get dragleave events when dragging between chrome and content.
Comment 4•14 years ago
|
||
The loss of dragleave when dragging between chrome and content is a regression from bug 130078. Before that chrome and content had separate widgets that sent drag exit events to their separate event state managers.
The loss of dragleave when dragging between iframes would be a regression from bug 352093 for the same reason.
Blocks: 130078, widget-removal
Keywords: regression
Comment 5•13 years ago
|
||
I this this should be fixed by the changes in bug 591249.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in bug 591249]
Assignee | ||
Updated•6 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
•