<AWT Dev> Patch for JTreg test java/awt/Mixing/LWPopupMenu.java

[Pavel Tisnovsky]

Hi,

can you please review patch for JTreg test
java/awt/Mixing/LWPopupMenu.java
(http://cr.openjdk.java.net/~ptisnovs/LWPopupMenu/)?

This test opens two frames - test dialog (used for printing messages and
so on) [Window1] and the frame with menu and button [Window2]. Sometimes
(probability is about 10% on my machine) the [Window2] is displayed
UNDER [Window1], not on the top. This causes test failure, because
[Window2] does not receive events when it is covered by another window.

Calling frame.toFront() after waiting for robot seems to solve this issue.

Thanks in advance,
Pavel Tisnovsky

[Anthony Petrov]

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.

--
best regards,
Anthony


On 10/01/2009 07:09 PM, Pavel Tisnovsky wrote:

> Hi,
>
> can you please review patch for JTreg test
> java/awt/Mixing/LWPopupMenu.java
> (http://cr.openjdk.java.net/~ptisnovs/LWPopupMenu/)?
>
> This test opens two frames - test dialog (used for printing messages and
> so on) [Window1] and the frame with menu and button [Window2]. Sometimes
> (probability is about 10% on my machine) the [Window2] is displayed
> UNDER [Window1], not on the top. This causes test failure, because
> [Window2] does not receive events when it is covered by another window.
>
> Calling frame.toFront() after waiting for robot seems to solve this issue.
>
> Thanks in advance,
> Pavel Tisnovsky

[Pavel Tisnovsky]

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.
>

[Anthony Petrov]

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.
>>
>

[Pavel Tisnovsky]

Hi Anthony,

thank you for your comments, I'll try Gnome instead of Fluxbox for
regression testing.

Pavel

Anthony Petrov wrote:

> 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.
>
> --