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)
Tracking
()
VERIFIED
FIXED
M15
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.
Reporter | ||
Comment 1•25 years ago
|
||
h'm, i saw bug 16081, where context menus appear on any form controls. perhaps related?
Assignee | ||
Comment 3•25 years ago
|
||
I don't see the described behavior, but I do get an assert about the roolup behavior.
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•25 years ago
|
||
We need to comsume the right button click event and do nothing with it.
Target Milestone: M14
Assignee | ||
Comment 5•25 years ago
|
||
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
Comment 7•25 years ago
|
||
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).
Comment 8•25 years ago
|
||
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).
Assignee | ||
Comment 9•25 years ago
|
||
Wait.... I am doing more testing
Assignee | ||
Comment 10•25 years ago
|
||
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
Assignee | ||
Comment 11•25 years ago
|
||
add to Whiteboard summary
Status: NEW → ASSIGNED
Whiteboard: fix in my tree
Assignee | ||
Comment 13•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•