Hi Clemens,
Ok. I checked it on Ubuntu 12.04 and the problem does exist. I also
observed that the problem is not reproducible 1.8.0-ea-b56. The old bug
is frozen, so I filed a new one (#8000528) and added the following comment:
Pavel Porvatov added a comment - 2012-10-08 20:43
This is a Linux specific problem and reproducible only in browsers.
AppletViewer works as expected. The problem is reproducible in old
builds but not reproducible with the following configuration:
Java Plug-in 11.0.2.56
Using JRE version 1.8.0-ea-b56 Java HotSpot(TM) Client VM
After some time the bug will be visible on bugs.sun.com and you will be
able observe bug state
Regards, Pavel
Hi Pavel,
As mentioned, the issue only exists on Linux.
Thanks, Clemens
2012/10/8 pavel porvatov<[email protected]>:
Hi Clemens,
I can't reproduce the problem with your test case on 7u7 as well. The
following info if from my java console:
Java Plug-in 1.6.0_35
Using JRE version 1.7.0_07-b32 Java HotSpot(TM) Client VM
I used Chrome. Firefox 10.0.7 works as well. Tested OS is: Microsoft Windows
[Version 6.1.7601]
Regards, Pavel.
Hi Pavel,
Thanks for taking a look at the testcase.
The bug triggering the testcase seems to have been fixed between
jdk8b55 and jdk8b56, although I am still able to reproduce the issue
with jdk7u7. I tried to add a comment to the report, however it seems
that functionality has been disabled.
For me the issue showed up with Firefox, Chrome and Opera on Fedora-17
64-bit, regardless using the oracle plugin or icedtea-web. Appletview
works as expected, however.
Unfourtunatly, the real application which made me create this
self-contained testcase still runs into the problem ...
Thanks again, Clemens
On 14.09.2012 3:36, Clemens Eisserer wrote:
Hi Pavel,
I was able to distill the problem to small, self-contained testcase,
which is available at: http://93.83.133.214/textfielddemo.zip
I've also created a short video, demonstrating the issue:
http://youtu.be/r1JDj5BuBOM
The JTextField opens up a JPopupMenu on<ENTER>, which can be closed
by clicking the JButton it contains.
However, after the popup is hidden, no editing is possible unless
focus is toggled once between the browser and another window.
Unfourtunatly the testcase only triggers the problem on Linux (tested
with jdk8+oracle plugin as well as openjdk7+icedtea-web both with
recent versions Firefox and Chrome), However, I've seen this issue
happen on Windows too when running the application I talked in the
first email.
It would be great if you could have a look.
Thank you in advance, Clemens
2011/7/30 Pavel Porvatov<[email protected]>:
Hi Clemens,
Hi,
I've developed a database applet where Swing widgets are connected to
RowSets using the SwingSet library (an old sourceforge project).
All queries are executed on the EDT, except for some background tasks
which sync with the UI using SwingUtilities.invokeLater().
When running the application over high-latency connections (EDT is
busy
for a few seconds), sometimes after a pending operation is finished I
can't
edit any JTextFields. The mouse-cursor changes when I move it over the
JTextField, but when I click into the JTextField the carret simply
does
not
appear - everything else (JMenu, JButtons, ...) works as expected - so
I
guess event delevery is still working as expected.
To make JTextField-editing work again, I have to transfer focus to
another
native window and back to the browser-window. A heavyweight JMenu
makes
it
work again too, whereas a lightweight one doesn't help.
Even worse, the problem does not manifest itself with low-latency
connections or when running as application.
I am completly puzzled :/
Any idea what could be the problem, or where / what for I should start
looking?
First of all it's not a good idea to keep the EDT thread busy for a
long
time and I think the best way is to rewrite application. Could you
please
make a small separated application that emulates EDT blocking and shows
the
problem?
Regards, Pavel
