Hmmm... Thanks for providing the info.
On the second thought, I see that that isn't a problem in the test. AWT
(and I presume, Swing) has many tests that work that way: display both a
test frame and the dialog with the instructions/test output. Which means
that hypothetically they all can fail. Do we want to add this toFront()
call in the majority of our automated tests? I think the answer is negative.
What we observe here is an awkward behavior of a particular window
manager - the Fluxbox. Note that XToolkit officially supports the
Metacity window manager only (in 6, the CDE/dtwm is supported as well).
Of course, sometimes we do indeed add some workarounds for rather
popular window managers, e.g. for KDE, or Compiz. This, however, is not
a general practice/requirement.
The list of officially supported window managers enables us to develop
regression tests that pass when a fix works, and fail when it doesn't.
And our tests are designed to work correctly on officially supported
window managers only, because other WMs may bring some side-effects
that, at least, should not be work-around'ed in the code of the tests
themselves.
So, this issue looks like an AWT bug, rather than a test problem.
Moreover, that isn't even a bug, but an RFE to add better support for
the Fluxbox in XToolkit.
--
best regards,
Anthony
On 10/1/2009 7:59 PM Pavel Tisnovsky wrote:
Hi Anthony,
sorry, I forget to mention system configuration:
RHEL 5.3 for x86_64, Fluxbox as window manager (it's NOT configured to
automa[t|g]ically change window order according to mouse position, so
it's behaviour is similar to MS Win...)
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5.3) (build 1.6.0_0-b16)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
and
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.1-r7c131a5e1ccf) (build
1.6.0_0-b16)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
on the same platform
Pavel
Anthony Petrov wrote:
Hi Pavel,
Thanks for the patch. I'm just curious on which platforms/software
versions do you experience such behavior?
Also, I think we need another waitForIdle() call just after calling
the toFront() to make sure it gets correctly processed.
