context menu over dropdown list makes the list persist

VERIFIED FIXED in M15

Status

()

Core
Layout: Form Controls
P3
major
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: rods (gone))

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in my tree, URL)

(Reporter)

Description

19 years ago
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

19 years ago
h'm, i saw bug 16081, where context menus appear on any form controls. perhaps
related?

Comment 2

19 years ago
Reassigning to Rod.
Assignee: karnaze → rods
(Assignee)

Comment 3

19 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

19 years ago
We need to comsume the right button click event and do nothing with it.
Target Milestone: M14
(Assignee)

Comment 5

19 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
(Assignee)

Comment 6

19 years ago
reassign
Assignee: rods → joki

Comment 7

19 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

19 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

19 years ago
Wait.... I am doing more testing
(Assignee)

Comment 10

19 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

19 years ago
add to Whiteboard summary
Status: NEW → ASSIGNED
Whiteboard: fix in my tree
(Assignee)

Comment 12

19 years ago
setting to M15
Target Milestone: M14 → M15
(Assignee)

Comment 13

18 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 15

17 years ago
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.