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>>
>
>
> 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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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>
>
> Regards, Pavel
>
>
> 2011/5/27 Pavel
> Porvatov
> <pavel.porvatov at oracle.com
> <mailto:pavel.porvatov at oracle.com>
> <mailto:pavel.porvatov at oracle.__com
> <mailto: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/>
>
> 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
>