<Swing Dev> DnD fails with JTextArea and JTextField
Sean Chou
zhouyx at linux.vnet.ibm.com
Mon Sep 26 09:48:49 UTC 2011
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.
About the first comment, do you mean to put the testcase and the fix
together
in a webrev ?
2011/9/26 Pavel Porvatov <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>
>
>> 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>
>>
>> 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>
>>
>> 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>
>>
>> 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
>>
>> Regards, Pavel
>>
>>
>> 2011/5/27 Pavel Porvatov <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/
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20110926/9b4ec921/attachment.html>
More information about the swing-dev
mailing list