Created attachment 15000 [details]
Screenshot demonstrating the effect

Does this happen for all applications?

(This is supposed to work fine, there's code in there
to handle this. So it's probably a really trivial
fix if someone wants to look at it.)

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

I can't reproduce, though I only have Xnest here to
test with. If someone with a real multihead setup
could investigate, I'd appreciate it.

I've reproduced the problem on several Gnome2 apps, but Mozilla 1.3.1
is unaffected.  gtk+1-applications also appear to be unaffected (I
only have one app to test). 

Doesn't happen to me with gnome-terminal, xchat, or epiphany 
(with recent cvs build of gtk/gnome)

I have tried it on a Multihead setup(with two heads) on a Solaris box
with sources based on April 1st HEAD. I could not reproduce the
problem. I tried with many applications like gnome-terminal, gedit,
ggv, xchat.

Markus, have you had the chance to try this with a later build?  Are
you still seeing the problem?  If not, think we'll have to close as
unreproducible...

I've reproduced the problem with GTK 2.2.2, RedHat 9, and GNOME 2.3.3
(apt-get from Nyquist's apt repository).

I only have Xinerama at work, so I'll try a CVS build in the morning.

Markus - more useful might be a step-by-step-by-step description
of how you are reproducing the problem.

Ah...  right:
1. Start Gnome application foo 
2. Move mouse cursor to other screen
3. <alt><tab> to application foo
4. Open File-menu using keyboard shortcut <alt>f
5. The menu opens on the same screen as the cursor

As you can see in the screenshot I attached, the menu opens as close
to the correct screen as possible, and at the correct y-coordinate. 
Changing the window focus behavior (click, mouse, sloppy) makes no
difference.

Could it be due to a buggy ATI driver?  I'm using SWcursor in XF86Config.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

Is this still behaving the same way?

It can't really plausibly be the video driver; the video
driver isn't involved here.

I still can't reproduce this with Xnest -scrns 2; it will
have to be debugged by someone who *can* reproduce it.

Owen, its a Xinerama problem. Using the following patch to establish a
fake 2x2 Xinerama setup allows me to trivially reproduce the problem.
Maybe a fake Xinerama mode would be a good thing to have available via a 
GDK_DEBUG flag, since Xnest +xinerama will probably remain useless
forever... 

Created attachment 21105 [details] [review]
fake Xinerama

The problem is the following code in gtk_menu_position() which 
gets run after the user function (which in this case is
gtk_menu_item_position_menu() and does the right thing).
The monitor here is the monitor determined from the pointer.
A possible fix might be to determine the monitor to clamp to
from the position returned by the user function.

  if (push_in)
    {
      menu_height = GTK_WIDGET (menu)->requisition.height;

      if (y + menu_height > monitor.y + monitor.height)
	{
	  scroll_offset -= y + menu_height - (monitor.y + monitor.height);
	  y = (monitor.y + monitor.height) - menu_height;
	}
  
      if (y < monitor.y)
	{
	  scroll_offset += monitor.y - y;
	  y = monitor.y;
	}
    }

  /* FIXME: should this be done in the various position_funcs ? */
  x = CLAMP (x, monitor.x, MAX (monitor.x, monitor.x + monitor.width -
requisition.width));

Hmm, determining the monitor from the position returned by the user
function doesn't work, since e.g. gtk_menu_item_position_menu() can
return positions which lie outside the monitor we're interested in 
(e.g. for the taller-than-screen menu example in testgtk). Guessing the
monitor from the coverage of the menu is not guaranteed to give the
right answer either. The only correct solution I can see is to have
the user function return the monitor number, by adding an extra gint*
parameter to GtkMenuPositionFunc. The breakage won't be too bad, since
old user functions can just ignore the extra parameter. What do you
think, Owen ?

Created attachment 21144 [details] [review]
fake Xinerama redone

I've redone the fake Xinerama stuff, putting the currently unused
multihead debug flag to a good use.

Playing with GDK_DEBUG=multihead showed another problem of the menu
positioning code in relation to Xinerama (see attached screenshot). If
you put the menu example from testgtk on the lower left faked Xinerama
monitor, far enough towards the bottom of the screen to make the
"Second menu bar" menu pop up towards the top of the screen, you see
that the menu comes up too small. The further down I move the menu
example, the smaller the menu gets. Things work correctly on the upper
left faced Xinerama monitor, so it must be some interaction between
multihead and the menu positioning/scrolling logic.

Created attachment 21146 [details]
further Xinerama menu problems

DEBUG=MULTIHEAD has a precise meaning, it means

 "Print warnings about usages that are unsafe in the
  presence of multiple windows/screens"

E.g., gdk_event_put() with NULL event->any.window
prints a warning for DEBUG=MULTIHEAD.

If you wanted to add DEBUG=XINERAMA or DEBUG=FAKEXINERAMA,
that would be fine. 

We *cannot* add another parameter to GtkMenuPositionFunc;
source compatibility matters as well as binary compatibility.

I think what I'd prefer is some function along the lines of:

 gtk_menu_set_monitor (GtkMenu *menu, int monitor);

or maybe:

 gtk_menu_set_attach_anchor (GtkMenu, GtkAnchorType anchor);

that you'd call from the GtkMenuPositionFunc.

Oops, I was grepping for GDK_DEBUG_MULTIHEAD, overlooking the uses of
the form GDK_NOTE(MULTIHEAD,...), so the multihead debug flag is in
fact used and has a precise meaning. Thats fine, I'll introduce
GDK_DEBUG_XINERAMA. I'll try the gtk_menu_set_monitor() approach for
fixing the actual bug.

The following patch implements gtk_menu_set_monitor() and uses it to
fix the original problem of this report. I'm going to open a new bug
to track the problems with scrolling menus and vertical Xinerama.

Created attachment 21170 [details] [review]
proposed patch

Patch comments: 

 - It would seem a little clearer to move the 
   first call to gdk_screen_get_monitor_geometry () inside
   the else {} of 'if (menu->position_func)

 - gtk_menu_set_monitor() docs should have 'see'
   to gdk_screen_get_monitor_geometry(), so that someone
   reading it who wonders 'what the heck is a monitor'
   knows where to look.

 - Minor wording quibble:

   "...since these may be beyond the monitor or 
    even screen boundaries for very long menus"

   Would read better as:

   "...since, for very long menus, these coordinates 
    may extend beyond the monitor boundaries or even
    the screen boundaries"

Other than that, looks fine to commit.

Committed with your changes.