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
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
Status: ASSIGNED → RESOLVED
Last Resolved: 18 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.