{5} Assigned, Active Tickets by Owner (Full Description) (13 matches)

http://lists.apple.com/archives/X11-users/2007/Nov/msg00311.html

I'm using version 2.1.3 on 10.5.1 and I'm experiencing the "focus loss" bug that many users reported months ago using Last.fm with AudioScrobbler plugin (as described at http://lists.apple.com/archives/x11-users/2007/Nov//msg00612.html ) while running Mercury Messenger with the "show current song from iTunes" setting enabled (I guessed this reading macosxhints FAQ (bug number 42, http://forums.macosxhints.com/showthread.php?t=80171&page=3 ); disabling that setting in Mercury fixed the problem

*** Original report on x11-users:

I run MacOSX 10.5.2 and X11 2.1.3.  Instead of Quartz I use Ion as my
X11 window manager (see http://modeemi.fi/~tuomov/ion/).
When I switch from X11 where I have a xterm open to another application
and hit Cmd-q to quit this Application, focus jumps back to X11 (as it
should) and the character 'q' shows up in my xterm (as it should not).
So obviously X11 receives the q part of Cmd-q as a key event.

BTW, this happens for me with every X application that has the focus
under X11, not only with xterm.


*** After a couple of posts Jeremy replied to a post of Tom:

Ok, I can reproduce it now... Step 6 was what I was missing.  It's
definitely ffm related (which means it's a bit low on the priority
list, sorry).

Please open a bug in our trac and an apple radar.

--Jeremy
On Feb 14, 2008, at 15:05, Tom Lane wrote:

> Jeremy Huddleston <jeremyhu@berkeley.edu> writes:
>> TextEdit exited, no q in the terminals.
>> I this is an issue... I just can't seem to reproduce it =/
>
> Okay, I tried using TextEdit.  Test case (again, 10.5.2 + 2.1.3, ffm
> on):
>
> 1. Open xterm window in upper left corner of display
> (the default place for first X11 window)
>
> 2. Open Finder window on Applications folder, scroll down
> to see TextEdit, move window to right side of screen
>
> 3. Double-click on TextEdit icon in Finder window;
> it opens an empty window partially overlapping the xterm
>
> 4. Click on the xterm window to make it topmost and focused.
> Note its cursor is now solid black.
>
> 5. Move cursor over an exposed part of TextEdit window and
> click to focus it.  Note xterm cursor changes to outline.
>
> 6. Move cursor back over the part of the TextEdit window that
> is obscuring part of xterm window.  Note xterm cursor changes
> to black (!!?)
>
> 7. Type command-Q.
>
> I get a Q in the xterm most of the time; if not, repeat from step 3.
>
> Step 4 seems to be important; without it the probability of a Q
> goes way down.
>
> The xterm cursor's behavior seems pretty bogus even without the Q
> issue.  X11 obviously has a different idea of which window has focus
> than the system does.  Some experimentation with multiple open X11
> windows shows the cursors change as if they have focus even when
> moving the mouse over a foreground TextEdit window that partially
> obscures all of them.
>
> 			regards, tom lane

When I use control-arrow-key to switch to another Space, if the cursor is within an X11 window and focus-follows-mouse is on, I'd expect that window to acquire focus. It doesn't though. Moving the mouse even slightly will cause it to acquire focus, but IMHO I shouldn't have to do that.

Some experimentation says that the behavior is the same when using the F8 view to switch spaces, though you have to be quite careful when clicking in the view not to move the mouse, else that motion will allow focus to be acquired.

Note: this is with 2.2.1 but the "version" menu hasn't yet got an entry for that.

We have a set of xview based programs. Using F8 and drag it is now possible to move an xview window from space x to space y. The problem is that once you activate a menu (in a pinnable window) selection on a given instance of an application in a given Space then all menu items for that instance are now stuck in that Space even if you move the main program window to another Space. If you then move the unpinned menu window with F8 the cursor offsets of the windows are off so that, if the menu is the active window, you move your cursor somewhere else (I haven't figured the pattern) on the current Space to activate its choices. At this point all new menus now appear in this new Space to which you moved the unpinned window.

XQuartz 2.2.1 - (xorg-server 1.4.0-apple8)

Jeremy, This is the bug report you requested in your post to x11-users@… (msg-id: <5CFCFFE2-0D8F-47FE-A3BB-E99B014406DF@…>)

This part of the bug is fixed in 2.3.2beta1 xorg-server 1.4.2-apple20: X11 windows used to gain focus when the mouse moved over them while they were obscured by an OSX window (e.g. Safari) which was the frontmost window.

The following still occurs (with 2.3.2beta1 xorg-server 1.4.2-apple20): The effect is only visible with wm_ffm true. Focus moves to partially obscured X11 windows only when X11 is the topmost application. If the X11 windows are interleaved with OSX windows with X11 in the foreground (e.g. xterm has focus and is topmost; Safari is next and partially obscures another X11 xterm), if I move my mouse out of the top xterm and over the Safari window (without raising Safari), then the xterm beneath the Safari window receives focus whenever the mouse hovers over the area that it occupies which is beneath Safari's window. However, I believe that is how the system has to work. On the other hand were OSX to support FFM for all applications, then I suppose this would not be correct behavior.

So this is not really a bug (I guess), and I do like the fact that I can interleave OSX and X11 windows (which way back was not possible). I would not wish to give up the interleaving. However, the focus is a bit distracting and may point to something under the hood which is not working as planned.