Something like this happens for me but for Gedit. I guess it's related to the metacity. My steps:

1) Launch Gedit (mouse should be in the primary monitor which is in the right of the secondary monitor and so 0,0 is in the secondary monitor - actually not exactly 0,0 because resolution of my secondary monitor differs from the primary and is aligned to bottom)
2) Maximize Gedit on the right monitor
3) Close Gedit
4) Open Gedit (mouse should be in the right monitor again)
- Gedit should be maximized in the right monitor in this step
5) Click on an menu item
6) move the pointer on one of the items in the menu list
Gedit jumps to the left monitor for me, although the menu list is still in the right monitor

This happens to me also and has done for years. It's extremely annoying. Is there any interest to fix this or is there more information needed?

I was able to reproduce this just now with Gnome 3.4.2 / Fedora 17.

(In reply to comment #3)
> I was able to reproduce this just now with Gnome 3.4.2 / Fedora 17.

Do you reproduce this in gedit or in evince? I can reproduce the problem but only with gedit. I guess it is a bug in mutter.

It goes through this code:
  gedit/gedit-app.c:780:gedit_app_create_window_real()
	gtk_window_maximize (GTK_WINDOW (window));

This sends a X event to the window manager:
  _NET_WM_STATE _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ

And gnome-shell/mutter receives it in src/core/window.c meta_window_client_message().

(In reply to comment #4)
> (In reply to comment #3)
> > I was able to reproduce this just now with Gnome 3.4.2 / Fedora 17.
> 
> Do you reproduce this in gedit or in evince? I can reproduce the problem but
> only with gedit. I guess it is a bug in mutter.

Actually, I hadn't tried gedit, but it does have the same behavior, so it makes sense that it might be a Mutter bug.

Note that if I open gedit by name, it appears on the same screen as the cursor. But if I open a document (which had last been viewed as maximized) in Nautilus, regardless of whether it's handled by gedit or Evince, it briefly displays it on the smaller (non-primary) screen, then moves it to the other screen.

> It goes through this code:
>   gedit/gedit-app.c:780:gedit_app_create_window_real()
>     gtk_window_maximize (GTK_WINDOW (window));
> 
> This sends a X event to the window manager:
>   _NET_WM_STATE _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ
> 
> And gnome-shell/mutter receives it in src/core/window.c
> meta_window_client_message().

Created attachment 229486 [details]
maximize.c

This small program triggers the same window jump. It is racy, so the jump will sometimes happen during gtk_statusbar_push and sometimes in gtk_statusbar_remove.

The test case has nothing to do with evince.  Re-assigning to mutter.

In mutter/src/core/window.c:meta_window_update_monitor(), I added:
  meta_topic (META_DEBUG_PLACEMENT,
              "meta_window_update_monitor: window %s moves from monitor %d to %d\n",
              window->desc, old->number, window->monitor->number);

And I notice the following logs when the bug happens:

meta_screen_get_monitor_for_window: window 0x1a00003 (maximize) has rect x=1366 y=27 w=1680 h=1023
meta_screen_get_monitor_for_rect: comparing with monitor 0: rect x=1366 y=0 w=1680 h=1050
meta_screen_get_monitor_for_rect: comparing with monitor 1: rect x=0 y=0 w=1366 h=768
meta_window_update_monitor: window 0x1a00003 (maximize) moves from monitor 1 to 0

The window was correctly positioned on the external monitor 1680x1050 and is wrongly moved to the laptop monitor 1366x768.

But in a small program using gdk_screen_get_monitor_at_point(), I notice that GDK and Mutter use different indexes for my monitors: my laptop monitor 1366x768 is #1 according to Mutter or #0 according to GDK. My external monitor 1680x1050 is #0 according to Mutter or #1 according to GDK. My primary monitor (gdk_screen_get_primary_monitor) is #1 (my external monitor). I wonder if it is related to the bug. I am still investigating.

I was looking at this problem last week, and basically I ended up with the following findings :

Mutter delays the window positioning in case the application resizes its window quickly after its creation. In the case of this bug, by the time mutter hits the positioning code, it has already received a maximize request for the same window.
And that's where is problem is, apparently a portion of the code supposed to maximize the window doesn't take into account the initial position computed by Mutter (which is, like Alban showed, correct). 

I believe that the bug in somewhere around here :

http://git.gnome.org/browse/mutter/tree/src/core/constraints.c?h=gnome-3-6#n576

When we call meta_window_maximize_internal(), we give newly computed position for the window (which is correct). And this maximize_internal() function saves this position into window->saved_rect.
Then meta_window_maximize_internal() calls recalc_window_features() to actually computed the maximized position. To do so, it needs to know which monitor has to be used to compute the new size of the window. And it does so by calling meta_window_get_outer_rect(). That function returns a position that isn't the one computed by mutter and stored in window->saved_rect.

I believe that's the core of the problem, we try to maximize using the coordinates in sync with the Xserver, not the newly computed coordinates.

I see 2 solutions to fix that problem, either for a sync of the coordinates from the Xserver, or change the function doing to maximization to take into account the futurue position of the window.

*** Bug 686646 has been marked as a duplicate of this bug. ***

Created attachment 229686 [details] [review]
[PATCH] Fix maximised window jumping to other monitor in dual monitor setup

Thanks for the explanation Lionel. I fixed it by changing the function doing to maximization to remember the initial position computed by Mutter in a way that will be used in the delayed positioning code. It seems to work and not have side effect but Mutter is complex, I might miss something. Reviews welcome!

*** Bug 674641 has been marked as a duplicate of this bug. ***

*** Bug 659658 has been marked as a duplicate of this bug. ***

*** Bug 679158 has been marked as a duplicate of this bug. ***

Looks good to me.

Created attachment 230110 [details] [review]
[PATCH] Fix maximised window jumping to other monitor in dual monitor setup

Similar patch, but with code moved into the constraints code that does the maximize, as suggested by Jasper on IRC.

The patch applies fine on git master and on branch gnome-3-6. But I assume we want the fix only on master?

(In reply to comment #16)
> Created an attachment (id=230110) [details] [review]
> [PATCH] Fix maximised window jumping to other monitor in dual monitor setup
> 
> Similar patch, but with code moved into the constraints code that does the
> maximize, as suggested by Jasper on IRC.
> 
> The patch applies fine on git master and on branch gnome-3-6. But I assume we
> want the fix only on master?

IMVVHO, this bug should be also fixed in 3.4 (if this is not too much hassle).  It is too visible, and 3.4 is available is LTS distros.

Created attachment 230190 [details] [review]
[PATCH] Initialize window->user_rect in the initial placement

Review of attachment 230190 [details] [review]:

This is fine for me.

Comment on attachment 230190 [details] [review]
[PATCH] Initialize window->user_rect in the initial placement

(In reply to comment #19)
> Review of attachment 230190 [details] [review]:
> 
> This is fine for me.

Thanks!
Pushed on master, commit e5b467.
Pushed on gnome-3-6, commit 0dee738.
Pushed on gnome-3-4, commit 844ad6f.

*** Bug 687069 has been marked as a duplicate of this bug. ***