Context menu on textareas open up in the upper left of the content area

RESOLVED FIXED in M17

Status

()

P3
normal
RESOLVED FIXED
19 years ago
11 years ago

People

(Reporter: cmattar, Assigned: mjudge)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Updated

19 years ago
Assignee: law → saari

Comment 1

19 years ago
Chris, is this one for you?
OS: Windows 98 → All
Hardware: PC → All
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).

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M14

Updated

19 years ago
Assignee: saari → sdagley
Status: ASSIGNED → NEW

Comment 3

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

Comment 4

19 years ago
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus

Comment 5

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

Comment 9

19 years ago
*** Bug 27363 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Target Milestone: M14 → M15

Comment 10

19 years ago
moving non-PDT+ M14 bugs to M15.

Comment 11

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


Comment 13

19 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 14

19 years ago
moving non-critical bugs to M17
Target Milestone: M16 → M17
(Reporter)

Comment 15

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

Comment 17

19 years ago
Ender-lite should fix this.
Assignee: buster → mjudge
(Assignee)

Comment 18

19 years ago
works great with ender-lite.
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Updated

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