2011/9/28 Artem Ananiev <[email protected]
<mailto:[email protected]>>
On 9/27/2011 5:19 AM, Sean Chou wrote:
Hi Pavel,
Is toolkit.realSync() doing the job of "sleep 10s and throw an
timeout exception" ?
Definitely, not. SunToolkit.realSync() is what Robot.waitForIdle()
was initially supposed to be: this call should wait until all the
pending events (native, Java) to be processed. Sometimes, however,
it fails to do so, e.g. when native events are turned into Java
events, and Java event handlers call more native methods - then the
TimeoutException is thrown.
Thanks,
Artem
I found the main thread exit after realSynch is invoked. Should
I catch
that exception?
bug6848475.java seems not catching it.
2011/9/26 Pavel Porvatov <[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
__
Hi Sean,
Hi Pavel,
Thanks for new comments. I was looking
at test\javax\swing\JTextArea\__6940863
and copied the copyright from there, and just put the
initialization part of the swing
code into EDT. I didn't find realSynch in Toolkit class
so used
synch. I'll modify
that.
The realSync is a SunToolkit method.
About the first comment, do you mean to put the
testcase and
the fix together
in a webrev ?
Yep! It's hard to reconstruct fix from different mails.
Don't forget
to select an appropriate folder for the test...
Thanks, Pavel
2011/9/26 Pavel Porvatov <[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
Hi Pavel,
Thanks for the comments. I modified the testcase
according to the comments,
please have a look at it again.
I tried to run with jtreg and it runs well.
Looks much better. Still have several comments:
1. Could you please sent complete fix as a webrev,
but not
parts of the fix as a single file?
2. Date of copyright...
3. You are still using Swing components on non-EDT
thread. As
I wrote before take a look at the
test\javax\swing\JSlider\__6848475\bug6848475.java
test...
4. Use toolkit.realSync() instead of toolkit.sync().
BTW: as
described in javadoc realSync cannot be invoked on
the EDT
thread...
Regards, Pavel
P.S. Sorry for my stubborn =) But on some machines not
accurate tests actually fail (e.g. on Solaris).
Therefore
later we must fix tests and that's a really boring
task...
2011/9/20 Pavel Porvatov
<[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
The have several comments :
1. Could you please read
http://openjdk.java.net/jtreg/
is it possible run your test via jtreg?
2. There is no copyright in the begin of test
3. There are no jtreg tags
4. All Swing code must be initialized on the
EDT thread
5. Keep test minimal as possible, please. It
helps other
people to understand your code.... E.g.
there is no need
to create JButton with listener.
6. Note that the "frame.setVisible(true)"
doesn't
guarantee that after that line Frame is
visible, you
should use toolkit.realSync() here
7. No TODO, please
8. Are you sure your test should pass if
exceptions
occurs (see your catch blocks)
Please take a look at other tests and use
them as a good
examples....
Regards, Pavel
Hi Pavel,
I wrote a test case for the behavior
of DefaultCaret.
Please take a look, it is
attached.
2011/9/15 Pavel Porvatov
<[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
Hi Pavel,
I'm comfortable with moving
the checking into
DefaultCaret#__updateSystemSelection method.
About regression test, I'm
not sure how to
write, because it contains user
operation. Can you
give me a similar test so I can
write one for this bug?
Yes, you can find a lot examples in the
test/javax/swing directory by word
Robot, e.g.
test\javax\swing\JSlider\__6848475\bug6848475.java.
One hint: use reflection ONLY if
there are no
another ways to write a test...
Regards, Pavel
2011/9/13 Pavel Porvatov
<[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
Hi Pavel ,
I'm sorry I didn't
make update for this
bug for a long time, and
here is some
recent investigation.
The scenario is as follows:
Suppose we are dragging
"abcde" over TextField
tf, which have "hello
dragging" as
its content. When we are
dragging from start
to end, there is a
cursor moving from
"h" to "g", which means the place to insert
"abcde" if we drop it.
When we dragging "abcde"
exit tf, there will
be a dragExit event, the
tf needs to
restore its original
status after we drag out.
Eg. if its cursor is
between "h" and
"e" in "hello", which appears like "h|ello",
when we are dragging
over it, it may like
"hello dr|agging", and when drag exit, it
needs to be "h|ello" again.
So in dragExit handler,
it calls
javax.swing.TransferHandler.__cleanup(false),
which
means only to restore
the original state.
cleanup calls
javax.swing.text.__JTextComponent.setDropLocation
to
set the cursor to original
position. And
setDropLocation calls
DefaultCaret.setDot and
DefaultCaret.moveDot
to set the state.
The problem is moveDot
doesn't know this is
just to restore the
original state,
it treats the invocation
as an action to
select something. And it
calls updateSystemSelection
which will
call
java.awt.datatransfer.__Clipboard.setContent.
And the selected content
is changed from "abcde"
to the original
selected part of "hello
dragging", then
the drop operation finds
it is not the string
dragged and nothing is
dropped.
So I made a simple
patch(attached) . It just
check if the textField
owns focus
before
updateSystemSelection, if it is not
focused, it does not
treat the moveDot as
a selection action and
does not
call
Clipboard.setContent. This works on Linux,
however, DefaultCaret is
shared by Linux and
Windows while windows
doesn't have
this problem. So I don't
think this is a
correct patch, but it
brings my question.
I think it is strange
for DefaultCaret to use
setDot and moveDot to
restore
original state,
especially moveDot will cause
an updateSystemSelection
operation,
which makes moveDot much
like an action from
user instead of just
restoring state.
I'm not sure why it
works well on windows, but
I don't think it is
right to call
updateSystemSelection or
it is not right to
use setDot and moveDot
to restore
the original state. Is
there any reason for that ?
Thanks for the patch! I
believe you are right
and we shouldn't update
system selection
clipboard when the component
doesn't have
focus. I'd like to modify
your fix and move
checking into the
DefaultCaret#__updateSystemSelection method:
if (this.dot != this.mark
&& component !=
null && component.hasFocus()) {
We also must write
regression tests for fixes
if possible, so an automatic
test is needed as
well. Could you please write
a test for the fix?
> I'm not sure why it works well on windows,
That's because Windows
doesn't have system
selection clipboard...
> Is there any reason for that ?
No, that's a just bug...
Regards, Pavel
2011/6/6 Pavel Porvatov
<[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
Hi,
I reported, but
the system doesn't reply
me a bug number.
It says "will give me
email",
but I haven't
got one yet. Is this the
right process,
or I might make a problem
when
reporting?
I don't know why the
system didn't report
bug ID, but your bug
was filed
successfully. You
can find it here:
http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7049024
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7049024>
Regards, Pavel
2011/5/27 Pavel
Porvatov
<[email protected]
<mailto:[email protected]>
<mailto:pavel.porvatov@oracle.__com
<mailto:[email protected]>>>
Hi Sean,
Hi all,
I
have a testcase related to DnD
failure
with JTextArea and
JTextField on linux. The
testcase
is as follows:
/*
*
DnDTest.java
*/
import
java.awt.Color;
import
java.awt.Component;
import
java.awt.Dimension;
import
java.awt.FlowLayout;
import
java.awt.Frame;
import
java.awt.event.WindowAdapter;
import
java.awt.event.WindowEvent;
import
javax.swing.JTextArea;
import
javax.swing.JTextField;
public
class DnDTest extends Frame {
Component c;
public
DnDTest() {
super("Single Frame --- AWT Frame");
super.setBackground(Color.__gray);
// set
layout here.
setLayout(new FlowLayout());
c = new
JTextArea("JTextArea
component");
c.setPreferredSize(new
Dimension(400, 100));
add(c);
c = new
JTextField("JTextField
component(No IM)");
c.setPreferredSize(new
Dimension(400, 20));
add(c);
addWindowListener(new
WindowAdapter() {
public void
windowClosing(WindowEvent event) {
System.exit(0);
}
});
setSize(850, 360);
setVisible(true);
}
public
static void main(String[] args) {
new
DnDTest();
}
}
Reproduce steps:
1. Run
the testcase with b143
2. Open
a new file with gedit and
input
some words like "abcde"
3. Drag
"abcde" into JTextField and
drop it
there.
4. Once
more, drag "abcde" into
JTextField and then move out of the
Frame
(keep draging) and drag
into
JTextField again and drop it.
Expectation:
The
second DnD inputs another
"abcde" into JTextField.
Result:
The
second DnD inputs nothing
into
JTextField.
Yes, looks
like a bug. The test case
works on
Windows as expected.
Investigation:
The
JTextArea as well has this
problem,
and in step 4, if we drag
"abcde" over JTextField and then
drop
into JTextArea, nothing
is input
into JTextArea either.
However,
if "abcde" is drag
into
JTextField or JTextArea
directly
or when JTextArea/Field are
empty as
in step 2, it works.
Are
there any comments? And can
anyone
file a bug for it please ?
Anybody can
file a bug,
http://bugreport.sun.com/__bugreport/
<http://bugreport.sun.com/bugreport/>
Regards, Pavel
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
