i'm using build 2000011808 on WinNT, to reproduce: 1)left click into the Summary text field. 2)right click into same field. 3)click on the link "Resolution:" *notice you don't go to that page when you click the link once* 4)click the link again. *mozilla loads the resolution page* That's pretty benign compared to what can happen if you don't left click into the field first. Try repeating the instructions, but skip step 1. You'll notice a context menu appear - that's ok, except it doesn't seem to apply completely. Try repeating the steps again from the beginning, but this time right click into the field twice - now it seems that you'll never be able to get out. And when you exit, mozilla might just crash for you.

The steps as described the first time are a DUP of bug 21390, "[4.xP] Clicking on Widget or link does nothing if menu open", but the problems with the two variations given (skipping step 1 and right-clicking in step 1) are new. I was unable to reproduce this with 2000-01-20-08-M13 on NT; no context menu showed at all when right-clicking over an <INPUT>, no matter how I tried. No context menu appeared. What did show up every time was a message in the console: >X Pos: 1243944 >Y Pos: 48 The same coordinates showed no matter what <INPUT> or <TEXTAREA> I clicked on, and no matter where; the coordinates seemed accurate clicking anywhere outside an <INPUT> or <TEXTAREA>. jelwell@singleclick.com, when you say "a context menu appear - that's ok, except it doesn't seem to apply completely", does this mean that the context menu that appears has items on it that you wouldn't expect? Can you recognize it - is it the same sort that you'd see after right-clicking on a link, on an image, or are the items just weird? Also, for the second variation, you say, "now it seems that you'll never be able to get out" - does this mean that clicking anywhere else does nothing, including on the menus? If so, this should be filed as a new bug, at a CRITICAL severity level, against either the "XP Toolkit/Widgets: Menus" component or the "HTML Form Controls" component, not sure which, but try the first of those.

If I launch mozilla, then load this bugzilla report, and make sure not to click anywhere. Then right click on the Summary text input field a Context menu appears that says looks just like the one that you get when you right click on nothing in the browser normally "Back, Forward, Reload, Stop, View page source, Bookmark this page, Save page as..., Select all, Copy" forward, stop and copy are grayed out. With the second variation: Yes, the menus are all made lifeless. I can't hit the back button. I can't even open a new browser window or mail, etc.. from the little buttons on the bottom left. A little note about the second variation (which involves right clicking twice) - don't forget to left click first (otherwise you'll end up with the first bug which involves the context menu. I just tested this on build 2000012400 (an M13 nightly).

Ok, in that case, the first variation is almost certainly because of bug 9701, "nsWebShell Key events not working until focus set in window (TAB, PgDn, ALT+, CTRL+)", assigned. The click is acting as if it wer on the page, because that's as far as the focus change gets. So it looks like this bug is about the second variation: 1. View this page. 2. Left-click in an input. 3. Right-click in the same input, release, right-click again. Result: Mozilla hangs. This could be an "Editor" bug, but trying "XP Toolkit/Widgets: Menus" first. sairuh, should this be started over as a new report for this issue only, for clarity?

for my own sanity (maybe it's my lack of food or staring at all these bugs too long), could you please break out these problems into separate cases? I'm having enough trouble keeping everthing in my head. There are problems with context menus in editor fields, i don't think they are xpmenu issues per se. Pushing back to trudelle because he plays the bug game better than i do.

i agree with sidr@albedo.net that the first variation is bug 9701 manifesting itself. i'm kinda unclean on the second part, tho: when you (ie, referring to sidr's last comment) mean "mozilla hangs" do you mean the following: 1. View this page. 2. Left-click in an input. 3. Right-click in the same input, release, right-click again. 4. Move mouse to the content (non-input) area. 5. Bring up context menu. 6. Select item in context menu (eg, View Source). result: nothing happens. need to click on content area again, ie, essentially report steps 4-6 to get the context menu to behave as expected. please let me know whether/how i might be misunderstanding this. i've updated the summary to reflect what i experience (feel free to change as needed :-). [tested on winNT using 2000-01-24-01-m13 non-comm bits]

sairuh@netscape.com: no not at all. It sounds like you're confusing the second case with the third. (sidr called them the first variation and the second variation) The third case has no context menu involved. Here's what's happening, that causes mozilla to stop responding to input: 1. View this page. 2. Left-click in an input. 3. Right-click in the same input, release, right-click again. result: Mozilla stops accepting mouse clicks(except that I can still click on the X to close the window). I can still mouse over the menus "File", "Edit", "View" ... however they don't open, their backgrounds just go gray. I can't type anywhere - because I can't select an input field to type on (despite the cursor still blinking in the original field). However keyboard shortcuts still work. <CTRL>N still opens a new window - but that window responds in the same way - no mouse clicks... I hope this clarifies the bug completely.

Only one defect is allowed per bug report, please be careful about this, since multiple defect bug reports can cause more problems than they solve. I'm resolving this bug as a dup of 21390, because of the first defect it describes. I think sidr is correct about the first variation being due to bug 9701, so there is no need for a separate bug report on that. I'll break the second variation out into a new bug.

*** This bug has been marked as a duplicate of 21390 ***

I thought they were all the same bug... I swear. Anyways, yep, duplicate and see bug 25026 for the crash bug.

I know, but it is better to file separate scenarios in different bugs anyway. We can always resolve as dup if they are, but it is a PITA to have to split a bug up. Only the assignee can determine if there is a common underlying problem.