Transfer of focus to Find/Replace dialog in Eclipse is considered focus stealing by Compiz

[Tristan Schmelcher]

Binary package hint: compiz

In Eclipse, the Find/Replace dialog automatically gains focus when it is opened, or when you press Ctrl+F while it is already open. However, Compiz considers this latter case to be focus stealing (even when focus stealing prevention is set to "Low"), despite the fact that both windows are part of the same app and the transfer is in response to a user action.

Repro steps:

1) Enable Compiz, then install compizconfig-settings-manager and enable focus stealing prevention in System -> Preferences -> Advanced
Desktop Effects Settings -> General Options -> Focus & Raise Behaviour.
2) Install Eclipse, open it, and open an editor window.
3) Press Ctrl+F to show the Find/Replace dialog.
  => The dialog gets focus, as expected.
4) Click on the editor to transfer focus back to it.
5) Press Ctrl+F again with the Find/Replace dialog already open.
  => Although the "Find:" text field gets focus, the actual Find/Replace window
does not, so that if you try to type then the keypresses go nowhere.

Expected: When Ctrl+F is pressed, the Find/Replace window should always get focus (except perhaps when using very strong focus stealing prevention)

I don't know whose bug this is, so I'm opening it against both the Eclipse and Compiz packages. I know you could argue that this is how focus stealing prevention is supposed to work, but it is definitely a bug to consider this focus stealing on the "Low" setting when it is so obviously not focus stealing.

Also opened with Eclipse upstream at https://bugs.eclipse.org/bugs/show_bug.cgi?id=235965.

Note that I have actually installed Eclipse directly from eclipse.org (Version: 3.3.1.1, Build id: M20071023-1652), not the Ubuntu repos, but I'm assuming that this would affect Ubuntu's package too.

$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04
$ apt-cache policy compiz
compiz:
  Installed: 1:0.7.4-0ubuntu6
  Candidate: 1:0.7.4-0ubuntu6
  Version table:
 *** 1:0.7.4-0ubuntu6 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

[Tristan Schmelcher (tschmelcher)]

Build ID: M20071023-1652

Steps To Reproduce:
1. On a Linux machine that uses Compiz (in my case Ubuntu Hardy 32-bit), turn on focus stealing prevention with any strength. (Install compizconfig-settings-manager, then go to System -> Preferences -> Advanced Desktop Effects Settings -> General Options -> Focus & Raise Behaviour.)
2. Open an editor window in Eclipse.
3. Press Ctrl+F to show the Find/Replace dialog.
  => The dialog gets focus, as expected.
4. Click on the editor to transfer focus back to it.
5. Press Ctrl+F again with the Find/Replace dialog already open.
  => Although the "Find:" text field gets focus, the actual Find/Replace window does not, so that if you try to type then the keypresses go nowhere.

Expected:

When Ctrl+F is pressed, the Find/Replace window should always get focus.

More information:

The bug does not occur if Compiz's focus stealing prevention is turned off.

[Tristan Schmelcher (tschmelcher)]

Also opened with Ubuntu at https://bugs.launchpad.net/eclipse/+bug/237819.

[Daniel-megert (daniel-megert)]

Moving to SWT as this works on other known platforms. Might be NON_ECLIPSE.

[st33med (st33med)]

Something else happens to me. I do the second Ctrl-F with the editor open and find/replace as well, but, instead of focusing the cursor on the text, it instead makes the Eclipse box in the window list flash as if it were updated or needs attention and does not focus on the Find/Replace window.
This is on the Ubuntu package of eclipse and compiz. I think this should be confirmed for both.

[Tristan Schmelcher (tschmelcher)]

st33med:

Now that you've pointed that out, I see that I get the flashing in the window list too. And it only goes away once I manually transfer focus to the Find/Replace dialog.

[st33med (st33med)]

GAH! It crashed my computer when I closed Eclipse...
I am trying to get a backtrace now. I had closed Find/Replace, still had compiz-configmangager open, and just hit the big x at the top, and it crashed Ubuntu. Not even trying to restart the kernel via Alt-Print Screen-K would work...

It could also be that I had PyDev plugin installed; it could be a number of things...

[st33med (st33med)]

Nvm, cannot reproduce (nor get backtrace installed because of wrong versions of yelp-dbgsym :()

[Gheorghe-ca (gheorghe-ca)]

Praveen to investigate on his Ubunutu.

[Pinnamur (pinnamur)]

I had turned ON the compiz focus stealing prevention, but couldn't notice the reported behavior against the latest level (GTK 2.14.x). The Find dialog always gets focus after repeated attempts.
This can be closed if the reported problem no longer appears.
If you are still seeing the problem, Can you please provide the GTK version against which the problem is noticed?

[Robert Ancell (robert-ancell)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Tristan Schmelcher (tschmelcher)]

Just checked on Jaunty and it seems to be fixed. The focus transfer is now only prevented if the focus stealing prevention level is set to Very High. If it is though then Eclipse still ends up with keypresses going nowhere, but that's an Eclipse bug.

Marking as Fix Released in Compiz. Leaving open in Eclipse to track the remaining ignored-keypresses bug.

[Tristan Schmelcher (tschmelcher)]

The problem now only occurs if the focus stealing prevention level is set to Very High, which I would say is not a bug. However, when set to that level, the issue with keypresses going nowhere is still present, which _is_ a bug.

[Niels Thykier (niels-thykier)]

Hi

Can you please verify if this still exists in the eclipse 3.5.1?

~Niels

[Niels Thykier (niels-thykier)]

Hi

I have not heard anything on this since my request 2009-10-12; I have not experienced this issue myself and as of such I will close this bug as invalid (considering it expired). If anyone can still reproduce this particular issue in the latest version of eclipse, please post so (or open a new bug against eclipse).

~Niels

[Ericwill (ericwill)]

Behavior is fixed from a GTK2 version that is now out of date, as per comment 4.