Start Apprunner. Open the forms-test, test8.html. Right click on any of the inputfields or textareas. The context-menu appears in the upper left of the content area. In the debug window, the following some really high coordinates appear, like: Y Pos: 1622888281 X Pos: 6551692 Y Pos: 48 X Pos: 0 Y Pos: 1622888281 X Pos: 6550312
Chris, is this one for you?
this also occurs on mac (comm. bits 2000010409) and linux (comm. bits 2000010408). was able to verify on win98 (comm. bits 200010408) --but, weirdly enough, i couldn't repro this problem on winNT (same bits as on win98).
Reassigning to Dagley. Steve, this is another menu positioning bug. I'm not sure where the problem is exactly, but the positioning code I've touched in is nsMenuPopupFrame::SyncViewWithFrame
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
More menu related bugs being passed to pinkerton
Assignee: sdagley → pinkerton
i fixed this earlier this week. can't find the bug number.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
h'm, this still happens for me: when i bring up a context menu in an input field (eg, plain ole text box), it appears in the upper-left of the content area. tested on winNT [2000-020108] and linux [2000-020209]. reopening. ckritzer, have you seen this/is this a known problem for you?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've done some more debugging on this and i now can see why this works on mac and not on win/linux, but i have no clue why we're in the predicament that we're in. Here's what's happening: If you break in nsXULPopupListenerImpl::LaunchPopup you'll see lines that look like: mouseEvent->GetClientX(&xPos); mouseEvent->GetClientY(&yPos); Stepping into either of these DOM event methods lands you in nsDOMEvent. The code basically walks up the parent widget chain all the way up to the top, adding the appropriate offset to the current event's mouse location. On mac, this works just fine. You can see it walk all the way up to the top-level window. On win32/linux however, there appears to be a break in the chain. The parent chain simply _ends_ before it ever gets close to the top-level window. As a result, we cannot correctly compute the location of the point in the window and cannot place the context menu correctly. I'm pushing this over to buster and cc'ing karnaze because everything I have no idea why the widget chain might be severed only on win32/linux. I suspect problems with how gfx text widgets co-exist with layout's widget chain.
Assignee: pinkerton → buster
Status: REOPENED → NEW
*** Bug 27363 has been marked as a duplicate of this bug. ***
moving non-PDT+ M14 bugs to M15.
*** Bug 29495 has been marked as a duplicate of this bug. ***
I can't reproduce this bug on my Linux nightly 2000-03-24-09. The first time I right-click on a text field the context menu correctly appears next to my cursor and the text field receives focus (i-beam appears within it). Subsequent clicks just give the text field focus, and the context menu never appears. Textareas just get focus and never pop up the context menu, even on the first right-click. Nevertheless, this problem sounds awfully similar to the problem I just reported in bug 33226. In fact, right-clicking on the DIV with the scrollbar in the test case for bug 33226 has the same effect as reported in this bug: the context menu appears in the top-left corner of the browser window.
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
moving non-critical bugs to M17
Target Milestone: M16 → M17
Now the context menus don't even appear when clicking on specific form fields. It might have something to do with embedding ender for those. Here's a list of form elements and the results: Context menu appears at correct position: <input type=image> <input type=submit> <button type=submit> Context menu doesn't appear: Any disabled form elements <input type=text> <textarea> <select> Hope this helps
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
Ender-lite should fix this.
Assignee: buster → mjudge
works great with ender-lite.
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.