Hi,
One more: I put the testcase under javax/swing/JTextArea because the bug
is filed toward it.
On Mon, Oct 10, 2011 at 3:35 PM, Sean Chou <zhouyx at linux.vnet.ibm.com>wrote:
> Hi Pavel, Artem,
>
> I run jtreg on another machine and it passes. The attachment is the
> testcase and patch.
>
> The following modification to testcase are done as suggested last time:
> 1. Copyright in agreed form (the ibm info)
> 2. Date in copyright
> 3. All swing code in EDT
> 4. Use realSync()
>
> Please have a look, thanks.
>
>
> On Thu, Sep 29, 2011 at 11:55 PM, Artem Ananiev <artem.ananiev at oracle.com>wrote:
>
>>
>> On 9/28/2011 9:48 PM, Sean Chou wrote:
>>
>>> Hi Artem,
>>>
>>> I can not validate the testcase after I changed to use realSynch,
>>> it always fails with throwing an exception.
>>> Testcase test\javax\swing\JSlider\**6848475\bug6848475.java fails
>>> on
>>> my machine with timeoutexception as
>>> well.
>>> I run the test in its directory with command like this:
>>> jtreg -verbose:all -testjdk:...j2sdk/ bug6848475.java
>>>
>>
>> It may be a bug with realSync() implementation, possibly related to
>>
>> 6421984: realSync throws InfiniteLoop some times.
>>
>> Thanks,
>>
>> Artem
>>
>> 2011/9/28 Artem Ananiev <artem.ananiev at oracle.com
>>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at oracle.com>>>
>>>
>>>
>>>
>>> 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 <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>>
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>
>>> >>>
>>>
>>> __
>>>
>>> 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 <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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
>>> <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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
>>> <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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
>>> <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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
>>> <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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>
>>>
>>> <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
>>> <pavel.porvatov at oracle.com
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>> <mailto:pavel.porvatov at oracle.**__com
>>>
>>> <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>> 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/>
>>>
>>> <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
>>>
>>>
>
>
> --
> Best Regards,
> Sean Chou
>
>
--
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111010/837ff5d0/attachment.html>