Closed Bug 26296 Opened 25 years ago Closed 24 years ago

context menu over dropdown list makes the list persist

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: rods)

References

()

Details

(Whiteboard: fix in my tree)

found this on both winNT [2000-020108, comm] and linux [2000-020209, comm].
(unable to use mac bits at the moment.)

to repro,
1. go to the above URL, or any page that has a dropdown list in it.
2. bring up a context menu while the mouse pointer is over the dropdown list.
3. click elsewhere to cancel context menu.

result: the context menu goes away, but the dropdown list remains open. even
after move to another virtual desktop (on linux) or minimize/close other windows
on the desktop (both winNT and linux). need to select something from the list to
make it go away.

expected: dropdown list shouldn't open when bringing up a context menu
(methinks) --or if it does, it shouldn't persist after cancelling the conext
menu anyhow.
h'm, i saw bug 16081, where context menus appear on any form controls. perhaps
related?
Reassigning to Rod.
Assignee: karnaze → rods
I don't see the described behavior, but I do get an assert about the roolup 
behavior.
Status: NEW → ASSIGNED
We need to comsume the right button click event and do nothing with it.
Target Milestone: M14
Set a break point in the DOMListener method MouseDown in nsListControlFrame and 
another break point in NS_NewMenuPopupFrame. The popup frame is created before 
the ListControlFrame gets a crack at the event, the ListControlFrame is 
cancelling the event (with my next checkin), but it gets it too late.

reassign to joki
Status: ASSIGNED → NEW
reassign
Assignee: rods → joki
The problem here is that the DOM always goes before frames. Hey, joki, could 
frames actually examine the DOM event and see if preventDefault has been set?  
If we gave them the ability to see the DOM event, then frames could check for 
this flag, and they could not perform certain default actions once someone else 
has taken over.

This would also solve the "double keyboard navigation" problem with select lists 
and the scrolling browser window (using arrow keys).
Of course even then we have an ordering issue.  For example, the select list's 
keyboard navigation (which is done in the frame code I think) should take 
precedence over keyboard navigation of the browser window (which is done in DOM 
code).

I talked to Vidur about this, and one idea he had was that some frames would 
need to be able to control when their events went into the DOM, e.g., instead of 
calling HandleDOMEvent first in presshell, give the frame some crack at sending 
the event into the DOM AFTER it has had a chance to process some events.

So, for example, we could add a (pardon the lame function name) 
HandleEventBeforeDOM function to frames and call that prior to sending the event 
into the DOM.  The select list would move much of its handling into this 
function and get it out of HandleEvent (which would be called after the event 
goes into the DOM).
Wait.... I am doing more testing
Wierd, now I am getting the events in the correct order. I am not sure what is 
going on, reassiging bug to me.

I have the fix. I just need to PreventCapture,Bubbling,Default behavior and all 
is well.
Assignee: joki → rods
add to Whiteboard summary
Status: NEW → ASSIGNED
Whiteboard: fix in my tree
setting to M15
Target Milestone: M14 → M15
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updating QA contact.
QA Contact: ckritzer → bsharma
Verified build 2001080603 os:winNT,win98
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.