13463 - [BLOCK] event state manager can't tell when frames it tracks go away

Status: VERIFIED FIXED

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

Description

[Mike Pinkerton (not reading bugmail)]

In the event state manager, there are several frames that are being held onto for
tracking mouse enter/leave and drag gesture things. However, the psuedo-event
generation is two-staged:

- tell the DOM
- tell the frame

If a listener in the dom (such as a drop listener) deletes the frame (user moved
a button on the toolbar, causing it to be deleted), then when control gets back
to the event state manager, the frame is dangling and we crash hard.

Hyatt also will have this problem with closing up xp-popups.

Comment 1

[Mike Pinkerton (not reading bugmail)]

adding dependency

Comment 2

[Mike Pinkerton (not reading bugmail)]

ccing rjc

Comment 3

[Robert John Churchill]

Can we up the priority on this to a P1 ???  This is a MAJOR blocker for
drag&drop work.

Comment 4

[joki (gone)]

Do you guys have a specific test case for me on this?  Because there is some
code in place for notification of frame destruction but some of the more recent
code (like the drag events), or older code with bugs might have a problem with
it.  I can try to fix a spot or two that I see but I won't know I'm fixing the
problems your seeing.

Comment 5

[Mike Pinkerton (not reading bugmail)]

a good test case is in navigator.js. uncomment the lines (around line 155):

rdfc.RemoveElement(objectRes, true);
rdfc.InsertElementAt(objectRes, newIndex, true);

and then drag a toolbar button in the personal toolbar and drop it somewhere
else.

If you can point me to this mechanism for frame deletion notification, maybe i
can make the drag gesture code use it. if it's something that i'm not doing
correctly, then this should be my bug.

Comment 6

[Mike Pinkerton (not reading bugmail)]

after talking to joki, i learned there is a mechanism for determining when frames
used by the eventStateManager go away. Post-beta, I'll get this working myself
since joki is overloaded.

taking over this bug (which should have been mine to begin with) and adding joki
to the cc list just in case he might care.

Comment 7

[Mike Pinkerton (not reading bugmail)]

m15 accepting

Comment 8

[leger]

Putting on [PDT]+ radar.

Comment 9

[Mike Pinkerton (not reading bugmail)]

moving dogfood-related d&d stuff back to M12. woohoo!

Comment 10

[Mike Pinkerton (not reading bugmail)]

priority now p1

Comment 11

[Mike Pinkerton (not reading bugmail)]

fix checked in.

Comment 12

[Jan Carpenter]

code level fix, pinkerton, can you verify the fix?