From alexander.zvegintsev at oracle.com Wed Oct 1 12:47:08 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 01 Oct 2014 16:47:08 +0400 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <542B1D67.1030400@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> Message-ID: <542BF7CC.5020409@oracle.com> Hello Vivi, the fix looks good to me in general, but we lost some functionality, here is some modified code from the previous version of the test: ButtonGroup btnGrp = new ButtonGroup(); btnGrp.add(radioBtn1); btnGrp.add(radioBtn2); btnGrp.add(radioBtn3); radioBtn1.setSelected(true); mainFrame.getContentPane().add(btnStart); mainFrame.getContentPane().add(radioBtn1); mainFrame.getContentPane().add(radioBtn2); mainFrame.getContentPane().add(new JButton("MIDDLE")); mainFrame.getContentPane().add(radioBtn3); mainFrame.getContentPane().add(btnEnd); After this fix we are not able to select "MIDDLE" button with a keyboard anymore. If we change ButtonGroup order to btnGrp.add(radioBtn3); btnGrp.add(radioBtn2); We get into a loop and we are unable to select btnEnd and all following components(Shift+Tab can help in that case). I think that these cases deserves some attention. -- Thanks, Alexander. On 10/01/2014 01:15 AM, Vivi An wrote: > Hello Alexander, > > Thanks for the review. > > New patch is available under > http://cr.openjdk.java.net/~van/8033699/webrev.06/ > > Regards, > > Vivi > > On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >> Hello Vivi, >> >> Since you are touching this code, could you please add missing >> @Override annotations? >> > Added >> void jumpToNextComponent(boolean next) { >> if (!getButtonGroupInfo()) >> return; >> >> This leads to an issue: we can't switch to a next component with a >> TAB key if JRadioButton >> is not in a ButtonGroup. (It may be a reason to write another test.) > Fixed >> >> private boolean isValidRadioButtonObj(Object obj) { >> return ((obj != null) && (obj instanceof JRadioButton) && >> ((JRadioButton) obj).isVisible() && >> ((JRadioButton) obj).isEnabled()); >> } > Fixed >> >> There is no need to do a null check before instanceof [1] >> >> * @param evt, the event object. >> * @param next, indicate if it's next one >> */ >> private void selectRadioButton(ActionEvent event, boolean next) { >> >> typo: evt should be event >> > Fixed >> >> I run the test and it fails at least on Linux. It happens due to a >> big auto delay: >> Robot holds key for too long so system sends TAB key multiple time. >> So I think auto delay should be about 100 ms. >> >> robot.setAutoDelay(300); >> >> It is enough to call it once after Robot creation, this will >> automatically add a 300 ms delay >> between Robot generated events (such as keyPress, mouseMove, etc). >> If you really want a delay between test runs please use Thread.sleep(). >> >> I see many calls to hitKey() and then to realSync(), so we can move >> realSync() call to the end of hitKey(). >> checkResult() may be combined with runTest(), hence we call one >> function instead of two. >> >> int sum = 0; >> for (int i = 0; i < testResults.length; i++) { >> if (testResults[i] == false) >> sum++; >> } >> >> if (sum != 0){ >> System.out.println("Total 5 tests, failed test(s): " + sum); >> throw new RuntimeException("Test failed."); >> } >> >> >> I don't think that this logic is applicable here, each test depends >> on previous: Test2 failure means that >> focus is on a wrong component, so all following tests will fail. >> BTW, this code is unreachable in case of test failure, since >> checkResult() already throws an exception. >> >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 > Test is updated, non-grouped radio button test is added, test passed > on Oracle Linux 5 u6 32 bits and Windows 7. >> >> -- >> Thanks, >> Alexander. >> >> On 09/18/2014 09:23 PM, Vivi An wrote: >>> Thank you Alexandr. >>> >>> Need one more review for this. Alexander, could you please take a >>> look at below fix? >>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>> >>> Thanks >>> >>> Vivi >>> >>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>> Hello Alex, >>>>> >>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>> You are right. Fixed now. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>> >>>>>> 528 if (e.isShiftDown()) { >>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>> 537 // ... >>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>> 539 } >>>>>> 540 } else if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>> 548 // ... >>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>> 550 } >>>>>> >>>>>> The code in the if/else branches is almost the same except the >>>>>> true/false argument. >>>>>> I would suggest to unify them in the following way: >>>>>> >>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>> } >>>>>> >>>>> Fixed. >>>>>> >>>>>> 510 if (next) >>>>>> 511 KeyboardFocusManager. >>>>>> 512 >>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>> 513 else >>>>>> 514 KeyboardFocusManager. >>>>>> 515 >>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>> >>>>>> This code can be also a little bit optimized: >>>>>> >>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>> firstBtn)); >>>>>> >>>>> It's different function call, one for focusNextComponent and the >>>>> other for focusPreviousComponent, not able to optimize in >>>>> suggested way. >>>>> >>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>> >>>>> Thanks >>>>> >>>>> Vivi >>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> ~ Vivi >>>>>>> >>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> I have missed one more case: >>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>> // jumpToNextComponent(true) >>>>>>>> 538 } >>>>>>>> 539 >>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>> e.isShiftDown()) { >>>>>>>> //jumpToNextComponent(false) >>>>>>>> 550 } >>>>>>>> 551 } >>>>>>>> >>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>> methods can be called. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>> Fixed. New Webrev: >>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>> >>>>>>>>> Thanks Alex. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> ~ Vivi >>>>>>>>> >>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>> Thanks Alexander. >>>>>>>>>>> >>>>>>>>>>> All items addressed except last one, please see comments >>>>>>>>>>> inline. >>>>>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>> >>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>> >>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>> >>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>> 545 >>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>> 548 >>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>> 549 } >>>>>>>>>>>> >>>>>>>>>>>> Should the first button be focused If next is true and last >>>>>>>>>>>> button is null? >>>>>>>>>>> Don't think last button could be null when this function is >>>>>>>>>>> triggered, last and first will always be set in case there >>>>>>>>>>> is at least one valid (enabled and visible) radio button in >>>>>>>>>>> the group. >>>>>>>>>> >>>>>>>>>> It seems that lastBtn != null and firstBtn != null checks >>>>>>>>>> are not necessary in this case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to >>>>>>>>>>>>>>> next/previous >>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that these both fields point to the same object. >>>>>>>>>>>>>> Is it possible to get rid of one of them? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>> Should the keyListener also be set to null to free the >>>>>>>>>>>>>> KeyHandler object? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() && >>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This check is used several times. It can be moved to a >>>>>>>>>>>>>> separate method. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>> 375 if (!(model instanceof DefaultButtonModel)) >>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>> 377 >>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>> 379 DefaultButtonModel bm = (DefaultButtonModel) >>>>>>>>>>>>>> model; >>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>> >>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null model. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>> >>>>>>>>>>>>>> The curElement variable declaration could be moved into >>>>>>>>>>>>>> the 'while' block. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 408 if (curElement instanceof JRadioButton && >>>>>>>>>>>>>> 409 ((JRadioButton) >>>>>>>>>>>>>> curElement).isVisible() && >>>>>>>>>>>>>> 410 ((JRadioButton) >>>>>>>>>>>>>> curElement).isEnabled()){ >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is possible to use 'continue' here to not put the >>>>>>>>>>>>>> other code inside the 'if' block. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn == >>>>>>>>>>>>>> null){ >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is not necessary to check the srcFound in the second >>>>>>>>>>>>>> 'if' because it should already have true value. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The code that retrieves elements from a button group is >>>>>>>>>>>>>> also used in the selectRadioButton() >>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and >>>>>>>>>>>>>>> JCheckBox all passed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vivi.an at oracle.com Wed Oct 1 20:40:17 2014 From: vivi.an at oracle.com (Vivi An) Date: Wed, 01 Oct 2014 13:40:17 -0700 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <542BF7CC.5020409@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> Message-ID: <542C66B1.90500@oracle.com> Thanks Alexander. I have some questions, please see comments inline. Regards, ~ Vivi On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: > Hello Vivi, > > the fix looks good to me in general, but we lost some functionality, By functionality, you mean the functionality of the test, am I right? > here is some modified code from the previous version of the test: > > ButtonGroup btnGrp = new ButtonGroup(); > btnGrp.add(radioBtn1); > btnGrp.add(radioBtn2); > btnGrp.add(radioBtn3); > radioBtn1.setSelected(true); > > mainFrame.getContentPane().add(btnStart); > mainFrame.getContentPane().add(radioBtn1); > mainFrame.getContentPane().add(radioBtn2); > mainFrame.getContentPane().add(new JButton("MIDDLE")); > mainFrame.getContentPane().add(radioBtn3); > mainFrame.getContentPane().add(btnEnd); Just double checked the test in previous version and current version, did not find a button "MIDDLE" like previous code snippet, or I misunderstood, this is pseudo code? Compare to the old test code, new changes made are: 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added to a panel ("box" in below code snippet) and then to main frame, border also added too to separate from new added non grouped single radio button 2) A single radio button (Not Grouped) is added to cover the bug found in last round 3) Tests 1- 6 are adjusted for preceding change to cover areas would like to test Below is snippet from latest version, the "box" is the panel which contains radio button group, a screenshot added too 110 mainFrame.getContentPane().add(btnStart); 111 mainFrame.getContentPane().add(box); 112 mainFrame.getContentPane().add(radioBtnSingle); 113 mainFrame.getContentPane().add(btnEnd); > > After this fix we are not able to select "MIDDLE" button with a > keyboard anymore. > If we change ButtonGroup order to > > btnGrp.add(radioBtn3); > btnGrp.add(radioBtn2); > > We get into a loop and we are unable to select btnEnd and all > following components(Shift+Tab can help in that case). > I think that these cases deserves some attention. > > -- > Thanks, > Alexander. > > On 10/01/2014 01:15 AM, Vivi An wrote: >> Hello Alexander, >> >> Thanks for the review. >> >> New patch is available under >> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >> >> Regards, >> >> Vivi >> >> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>> Hello Vivi, >>> >>> Since you are touching this code, could you please add missing >>> @Override annotations? >>> >> Added >>> void jumpToNextComponent(boolean next) { >>> if (!getButtonGroupInfo()) >>> return; >>> >>> This leads to an issue: we can't switch to a next component with a >>> TAB key if JRadioButton >>> is not in a ButtonGroup. (It may be a reason to write another test.) >> Fixed >>> >>> private boolean isValidRadioButtonObj(Object obj) { >>> return ((obj != null) && (obj instanceof JRadioButton) && >>> ((JRadioButton) obj).isVisible() && >>> ((JRadioButton) obj).isEnabled()); >>> } >> Fixed >>> >>> There is no need to do a null check before instanceof [1] >>> >>> * @param evt, the event object. >>> * @param next, indicate if it's next one >>> */ >>> private void selectRadioButton(ActionEvent event, boolean next) { >>> >>> typo: evt should be event >>> >> Fixed >>> >>> I run the test and it fails at least on Linux. It happens due to a >>> big auto delay: >>> Robot holds key for too long so system sends TAB key multiple time. >>> So I think auto delay should be about 100 ms. >>> >>> robot.setAutoDelay(300); >>> >>> It is enough to call it once after Robot creation, this will >>> automatically add a 300 ms delay >>> between Robot generated events (such as keyPress, mouseMove, etc). >>> If you really want a delay between test runs please use Thread.sleep(). >>> >>> I see many calls to hitKey() and then to realSync(), so we can move >>> realSync() call to the end of hitKey(). >>> checkResult() may be combined with runTest(), hence we call one >>> function instead of two. >>> >>> int sum = 0; >>> for (int i = 0; i < testResults.length; i++) { >>> if (testResults[i] == false) >>> sum++; >>> } >>> >>> if (sum != 0){ >>> System.out.println("Total 5 tests, failed test(s): " + >>> sum); >>> throw new RuntimeException("Test failed."); >>> } >>> >>> >>> I don't think that this logic is applicable here, each test depends >>> on previous: Test2 failure means that >>> focus is on a wrong component, so all following tests will fail. >>> BTW, this code is unreachable in case of test failure, since >>> checkResult() already throws an exception. >>> >>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>> >> Test is updated, non-grouped radio button test is added, test passed >> on Oracle Linux 5 u6 32 bits and Windows 7. >>> >>> -- >>> Thanks, >>> Alexander. >>> >>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>> Thank you Alexandr. >>>> >>>> Need one more review for this. Alexander, could you please take a >>>> look at below fix? >>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>> >>>> Thanks >>>> >>>> Vivi >>>> >>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>> Hello Alex, >>>>>> >>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>> You are right. Fixed now. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>> >>>>>>> 528 if (e.isShiftDown()) { >>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>> 537 // ... >>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>> 539 } >>>>>>> 540 } else if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>> 548 // ... >>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>> 550 } >>>>>>> >>>>>>> The code in the if/else branches is almost the same except the >>>>>>> true/false argument. >>>>>>> I would suggest to unify them in the following way: >>>>>>> >>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>> } >>>>>>> >>>>>> Fixed. >>>>>>> >>>>>>> 510 if (next) >>>>>>> 511 KeyboardFocusManager. >>>>>>> 512 >>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>> 513 else >>>>>>> 514 KeyboardFocusManager. >>>>>>> 515 >>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>> >>>>>>> This code can be also a little bit optimized: >>>>>>> >>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>> firstBtn)); >>>>>>> >>>>>> It's different function call, one for focusNextComponent and the >>>>>> other for focusPreviousComponent, not able to optimize in >>>>>> suggested way. >>>>>> >>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>> >>>>>> Thanks >>>>>> >>>>>> Vivi >>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> Thank you >>>>>>>> >>>>>>>> ~ Vivi >>>>>>>> >>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> I have missed one more case: >>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>> // jumpToNextComponent(true) >>>>>>>>> 538 } >>>>>>>>> 539 >>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>> e.isShiftDown()) { >>>>>>>>> //jumpToNextComponent(false) >>>>>>>>> 550 } >>>>>>>>> 551 } >>>>>>>>> >>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>> methods can be called. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>> Fixed. New Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>> >>>>>>>>>> Thanks Alex. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> ~ Vivi >>>>>>>>>> >>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>> >>>>>>>>>>>> All items addressed except last one, please see comments >>>>>>>>>>>> inline. >>>>>>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>> >>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>> >>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>> 545 >>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>> 548 >>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>> 549 } >>>>>>>>>>>>> >>>>>>>>>>>>> Should the first button be focused If next is true and >>>>>>>>>>>>> last button is null? >>>>>>>>>>>> Don't think last button could be null when this function is >>>>>>>>>>>> triggered, last and first will always be set in case there >>>>>>>>>>>> is at least one valid (enabled and visible) radio button in >>>>>>>>>>>> the group. >>>>>>>>>>> >>>>>>>>>>> It seems that lastBtn != null and firstBtn != null checks >>>>>>>>>>> are not necessary in this case. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to >>>>>>>>>>>>>>>> next/previous >>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>> Should the keyListener also be set to null to free the >>>>>>>>>>>>>>> KeyHandler object? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() >>>>>>>>>>>>>>> && ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This check is used several times. It can be moved to a >>>>>>>>>>>>>>> separate method. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>> 375 if (!(model instanceof DefaultButtonModel)) >>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>> 379 DefaultButtonModel bm = >>>>>>>>>>>>>>> (DefaultButtonModel) model; >>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null >>>>>>>>>>>>>>> model. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The curElement variable declaration could be moved >>>>>>>>>>>>>>> into the 'while' block. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 408 if (curElement instanceof JRadioButton && >>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is possible to use 'continue' here to not put the >>>>>>>>>>>>>>> other code inside the 'if' block. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn == >>>>>>>>>>>>>>> null){ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is not necessary to check the srcFound in the second >>>>>>>>>>>>>>> 'if' because it should already have true value. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The code that retrieves elements from a button group is >>>>>>>>>>>>>>> also used in the selectRadioButton() >>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and >>>>>>>>>>>>>>>> JCheckBox all passed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fjaghjec.png Type: image/png Size: 32466 bytes Desc: not available URL: From alexander.zvegintsev at oracle.com Thu Oct 2 07:20:01 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 02 Oct 2014 11:20:01 +0400 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <542C66B1.90500@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> Message-ID: <542CFCA1.5050008@oracle.com> Sorry, I wasn't clear, provided code with the "MIDDLE" button is just an example what user can write (pretty odd one btw) it is not in your tests. By lost functionality I mean that after this fix this user can't navigate to the "MIDDLE" button via keyboard (or to the btnEnd after ButtonGroup reordering). -- Thanks, Alexander. 02.10.2014 0:40, Vivi An wrote: > Thanks Alexander. > > I have some questions, please see comments inline. > > Regards, > > ~ Vivi > > On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >> Hello Vivi, >> >> the fix looks good to me in general, but we lost some functionality, > By functionality, you mean the functionality of the test, am I right? > >> here is some modified code from the previous version of the test: >> >> ButtonGroup btnGrp = new ButtonGroup(); >> btnGrp.add(radioBtn1); >> btnGrp.add(radioBtn2); >> btnGrp.add(radioBtn3); >> radioBtn1.setSelected(true); >> >> mainFrame.getContentPane().add(btnStart); >> mainFrame.getContentPane().add(radioBtn1); >> mainFrame.getContentPane().add(radioBtn2); >> mainFrame.getContentPane().add(new JButton("MIDDLE")); >> mainFrame.getContentPane().add(radioBtn3); >> mainFrame.getContentPane().add(btnEnd); > Just double checked the test in previous version and current version, > did not find a button "MIDDLE" like previous code snippet, or I > misunderstood, this is pseudo code? > Compare to the old test code, new changes made are: > 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added to a > panel ("box" in below code snippet) and then to main frame, border > also added too to separate from new added non grouped single radio button > 2) A single radio button (Not Grouped) is added to cover the bug found > in last round > 3) Tests 1- 6 are adjusted for preceding change to cover areas would > like to test > > Below is snippet from latest version, the "box" is the panel which > contains radio button group, a screenshot added too > 110 mainFrame.getContentPane().add(btnStart); > 111 mainFrame.getContentPane().add(box); > 112 mainFrame.getContentPane().add(radioBtnSingle); > 113 mainFrame.getContentPane().add(btnEnd); > > > >> >> After this fix we are not able to select "MIDDLE" button with a >> keyboard anymore. >> If we change ButtonGroup order to >> >> btnGrp.add(radioBtn3); >> btnGrp.add(radioBtn2); >> >> We get into a loop and we are unable to select btnEnd and all >> following components(Shift+Tab can help in that case). >> I think that these cases deserves some attention. >> >> -- >> Thanks, >> Alexander. >> >> On 10/01/2014 01:15 AM, Vivi An wrote: >>> Hello Alexander, >>> >>> Thanks for the review. >>> >>> New patch is available under >>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>> >>> Regards, >>> >>> Vivi >>> >>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>> Hello Vivi, >>>> >>>> Since you are touching this code, could you please add missing >>>> @Override annotations? >>>> >>> Added >>>> void jumpToNextComponent(boolean next) { >>>> if (!getButtonGroupInfo()) >>>> return; >>>> >>>> This leads to an issue: we can't switch to a next component with a >>>> TAB key if JRadioButton >>>> is not in a ButtonGroup. (It may be a reason to write another test.) >>> Fixed >>>> >>>> private boolean isValidRadioButtonObj(Object obj) { >>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>> ((JRadioButton) obj).isVisible() && >>>> ((JRadioButton) obj).isEnabled()); >>>> } >>> Fixed >>>> >>>> There is no need to do a null check before instanceof [1] >>>> >>>> * @param evt, the event object. >>>> * @param next, indicate if it's next one >>>> */ >>>> private void selectRadioButton(ActionEvent event, boolean next) { >>>> >>>> typo: evt should be event >>>> >>> Fixed >>>> >>>> I run the test and it fails at least on Linux. It happens due to a >>>> big auto delay: >>>> Robot holds key for too long so system sends TAB key multiple time. >>>> So I think auto delay should be about 100 ms. >>>> >>>> robot.setAutoDelay(300); >>>> >>>> It is enough to call it once after Robot creation, this will >>>> automatically add a 300 ms delay >>>> between Robot generated events (such as keyPress, mouseMove, etc). >>>> If you really want a delay between test runs please use >>>> Thread.sleep(). >>>> >>>> I see many calls to hitKey() and then to realSync(), so we can move >>>> realSync() call to the end of hitKey(). >>>> checkResult() may be combined with runTest(), hence we call one >>>> function instead of two. >>>> >>>> int sum = 0; >>>> for (int i = 0; i < testResults.length; i++) { >>>> if (testResults[i] == false) >>>> sum++; >>>> } >>>> >>>> if (sum != 0){ >>>> System.out.println("Total 5 tests, failed test(s): " + >>>> sum); >>>> throw new RuntimeException("Test failed."); >>>> } >>>> >>>> >>>> I don't think that this logic is applicable here, each test depends >>>> on previous: Test2 failure means that >>>> focus is on a wrong component, so all following tests will fail. >>>> BTW, this code is unreachable in case of test failure, since >>>> checkResult() already throws an exception. >>>> >>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>> >>> Test is updated, non-grouped radio button test is added, test >>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>> >>>> -- >>>> Thanks, >>>> Alexander. >>>> >>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>> Thank you Alexandr. >>>>> >>>>> Need one more review for this. Alexander, could you please take a >>>>> look at below fix? >>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>> >>>>> Thanks >>>>> >>>>> Vivi >>>>> >>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>> Hello Alex, >>>>>>> >>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>> You are right. Fixed now. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>> >>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>> 537 // ... >>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>> 539 } >>>>>>>> 540 } else if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>> 548 // ... >>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>> 550 } >>>>>>>> >>>>>>>> The code in the if/else branches is almost the same except >>>>>>>> the true/false argument. >>>>>>>> I would suggest to unify them in the following way: >>>>>>>> >>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>> } >>>>>>>> >>>>>>> Fixed. >>>>>>>> >>>>>>>> 510 if (next) >>>>>>>> 511 KeyboardFocusManager. >>>>>>>> 512 >>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>> 513 else >>>>>>>> 514 KeyboardFocusManager. >>>>>>>> 515 >>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>> >>>>>>>> This code can be also a little bit optimized: >>>>>>>> >>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>>> firstBtn)); >>>>>>>> >>>>>>> It's different function call, one for focusNextComponent and >>>>>>> the other for focusPreviousComponent, not able to optimize in >>>>>>> suggested way. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Vivi >>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> Thank you >>>>>>>>> >>>>>>>>> ~ Vivi >>>>>>>>> >>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> I have missed one more case: >>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>> 538 } >>>>>>>>>> 539 >>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>>> e.isShiftDown()) { >>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>> 550 } >>>>>>>>>> 551 } >>>>>>>>>> >>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>> methods can be called. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> Thanks Alex. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> ~ Vivi >>>>>>>>>>> >>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>> >>>>>>>>>>>>> All items addressed except last one, please see comments >>>>>>>>>>>>> inline. >>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>> >>>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>>> >>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>> 545 >>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>> 548 >>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should the first button be focused If next is true and >>>>>>>>>>>>>> last button is null? >>>>>>>>>>>>> Don't think last button could be null when this function >>>>>>>>>>>>> is triggered, last and first will always be set in case >>>>>>>>>>>>> there is at least one valid (enabled and visible) radio >>>>>>>>>>>>> button in the group. >>>>>>>>>>>> >>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null checks >>>>>>>>>>>> are not necessary in this case. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to >>>>>>>>>>>>>>>>> next/previous >>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>> Should the keyListener also be set to null to free the >>>>>>>>>>>>>>>> KeyHandler object? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() >>>>>>>>>>>>>>>> && ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This check is used several times. It can be moved to a >>>>>>>>>>>>>>>> separate method. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>> 375 if (!(model instanceof DefaultButtonModel)) >>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = >>>>>>>>>>>>>>>> (DefaultButtonModel) model; >>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null >>>>>>>>>>>>>>>> model. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The curElement variable declaration could be moved >>>>>>>>>>>>>>>> into the 'while' block. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 408 if (curElement instanceof JRadioButton && >>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put the >>>>>>>>>>>>>>>> other code inside the 'if' block. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn == >>>>>>>>>>>>>>>> null){ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the second >>>>>>>>>>>>>>>> 'if' because it should already have true value. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The code that retrieves elements from a button group is >>>>>>>>>>>>>>>> also used in the selectRadioButton() >>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and >>>>>>>>>>>>>>>>> JCheckBox all passed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From vivi.an at oracle.com Thu Oct 2 21:46:10 2014 From: vivi.an at oracle.com (Vivi An) Date: Thu, 02 Oct 2014 14:46:10 -0700 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <542CFCA1.5050008@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> Message-ID: <542DC7A2.5000503@oracle.com> Thanks Alexander. Will look into it. Regards, ~ Vivi On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: > Sorry, I wasn't clear, > provided code with the "MIDDLE" button is just an example what user > can write (pretty odd one btw) > it is not in your tests. > > By lost functionality I mean that after this fix this user can't > navigate to the "MIDDLE" button via keyboard > (or to the btnEnd after ButtonGroup reordering). > > -- > Thanks, > Alexander. > 02.10.2014 0:40, Vivi An wrote: >> Thanks Alexander. >> >> I have some questions, please see comments inline. >> >> Regards, >> >> ~ Vivi >> >> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>> Hello Vivi, >>> >>> the fix looks good to me in general, but we lost some functionality, >> By functionality, you mean the functionality of the test, am I right? >> >>> here is some modified code from the previous version of the test: >>> >>> ButtonGroup btnGrp = new ButtonGroup(); >>> btnGrp.add(radioBtn1); >>> btnGrp.add(radioBtn2); >>> btnGrp.add(radioBtn3); >>> radioBtn1.setSelected(true); >>> >>> mainFrame.getContentPane().add(btnStart); >>> mainFrame.getContentPane().add(radioBtn1); >>> mainFrame.getContentPane().add(radioBtn2); >>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>> mainFrame.getContentPane().add(radioBtn3); >>> mainFrame.getContentPane().add(btnEnd); >> Just double checked the test in previous version and current version, >> did not find a button "MIDDLE" like previous code snippet, or I >> misunderstood, this is pseudo code? >> Compare to the old test code, new changes made are: >> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added to >> a panel ("box" in below code snippet) and then to main frame, border >> also added too to separate from new added non grouped single radio button >> 2) A single radio button (Not Grouped) is added to cover the bug >> found in last round >> 3) Tests 1- 6 are adjusted for preceding change to cover areas would >> like to test >> >> Below is snippet from latest version, the "box" is the panel which >> contains radio button group, a screenshot added too >> 110 mainFrame.getContentPane().add(btnStart); >> 111 mainFrame.getContentPane().add(box); >> 112 mainFrame.getContentPane().add(radioBtnSingle); >> 113 mainFrame.getContentPane().add(btnEnd); >> >> >> >>> >>> After this fix we are not able to select "MIDDLE" button with a >>> keyboard anymore. >>> If we change ButtonGroup order to >>> >>> btnGrp.add(radioBtn3); >>> btnGrp.add(radioBtn2); >>> >>> We get into a loop and we are unable to select btnEnd and all >>> following components(Shift+Tab can help in that case). >>> I think that these cases deserves some attention. >>> >>> -- >>> Thanks, >>> Alexander. >>> >>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>> Hello Alexander, >>>> >>>> Thanks for the review. >>>> >>>> New patch is available under >>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>> >>>> Regards, >>>> >>>> Vivi >>>> >>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>> Hello Vivi, >>>>> >>>>> Since you are touching this code, could you please add missing >>>>> @Override annotations? >>>>> >>>> Added >>>>> void jumpToNextComponent(boolean next) { >>>>> if (!getButtonGroupInfo()) >>>>> return; >>>>> >>>>> This leads to an issue: we can't switch to a next component with a >>>>> TAB key if JRadioButton >>>>> is not in a ButtonGroup. (It may be a reason to write another test.) >>>> Fixed >>>>> >>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>>> ((JRadioButton) obj).isVisible() && >>>>> ((JRadioButton) obj).isEnabled()); >>>>> } >>>> Fixed >>>>> >>>>> There is no need to do a null check before instanceof [1] >>>>> >>>>> * @param evt, the event object. >>>>> * @param next, indicate if it's next one >>>>> */ >>>>> private void selectRadioButton(ActionEvent event, boolean next) { >>>>> >>>>> typo: evt should be event >>>>> >>>> Fixed >>>>> >>>>> I run the test and it fails at least on Linux. It happens due to a >>>>> big auto delay: >>>>> Robot holds key for too long so system sends TAB key multiple time. >>>>> So I think auto delay should be about 100 ms. >>>>> >>>>> robot.setAutoDelay(300); >>>>> >>>>> It is enough to call it once after Robot creation, this will >>>>> automatically add a 300 ms delay >>>>> between Robot generated events (such as keyPress, mouseMove, etc). >>>>> If you really want a delay between test runs please use >>>>> Thread.sleep(). >>>>> >>>>> I see many calls to hitKey() and then to realSync(), so we can >>>>> move realSync() call to the end of hitKey(). >>>>> checkResult() may be combined with runTest(), hence we call one >>>>> function instead of two. >>>>> >>>>> int sum = 0; >>>>> for (int i = 0; i < testResults.length; i++) { >>>>> if (testResults[i] == false) >>>>> sum++; >>>>> } >>>>> >>>>> if (sum != 0){ >>>>> System.out.println("Total 5 tests, failed test(s): " + >>>>> sum); >>>>> throw new RuntimeException("Test failed."); >>>>> } >>>>> >>>>> >>>>> I don't think that this logic is applicable here, each test >>>>> depends on previous: Test2 failure means that >>>>> focus is on a wrong component, so all following tests will fail. >>>>> BTW, this code is unreachable in case of test failure, since >>>>> checkResult() already throws an exception. >>>>> >>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>> >>>> Test is updated, non-grouped radio button test is added, test >>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>> >>>>> -- >>>>> Thanks, >>>>> Alexander. >>>>> >>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>> Thank you Alexandr. >>>>>> >>>>>> Need one more review for this. Alexander, could you please take a >>>>>> look at below fix? >>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>> >>>>>> Thanks >>>>>> >>>>>> Vivi >>>>>> >>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>> Hello Alex, >>>>>>>> >>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>> You are right. Fixed now. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>> >>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>> 537 // ... >>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>> 539 } >>>>>>>>> 540 } else if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>> 548 // ... >>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>> 550 } >>>>>>>>> >>>>>>>>> The code in the if/else branches is almost the same except >>>>>>>>> the true/false argument. >>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>> >>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>> } >>>>>>>>> >>>>>>>> Fixed. >>>>>>>>> >>>>>>>>> 510 if (next) >>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>> 512 >>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>> 513 else >>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>> 515 >>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>> >>>>>>>>> This code can be also a little bit optimized: >>>>>>>>> >>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>>>> firstBtn)); >>>>>>>>> >>>>>>>> It's different function call, one for focusNextComponent and >>>>>>>> the other for focusPreviousComponent, not able to optimize in >>>>>>>> suggested way. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Vivi >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you >>>>>>>>>> >>>>>>>>>> ~ Vivi >>>>>>>>>> >>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> I have missed one more case: >>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>> 538 } >>>>>>>>>>> 539 >>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>>>> e.isShiftDown()) { >>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>> 550 } >>>>>>>>>>> 551 } >>>>>>>>>>> >>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>>> methods can be called. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> ~ Vivi >>>>>>>>>>>> >>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>> >>>>>>>>>>>>>> All items addressed except last one, please see comments >>>>>>>>>>>>>> inline. >>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>> >>>>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>>>> >>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Should the first button be focused If next is true and >>>>>>>>>>>>>>> last button is null? >>>>>>>>>>>>>> Don't think last button could be null when this function >>>>>>>>>>>>>> is triggered, last and first will always be set in case >>>>>>>>>>>>>> there is at least one valid (enabled and visible) radio >>>>>>>>>>>>>> button in the group. >>>>>>>>>>>>> >>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to >>>>>>>>>>>>>>>>>> next/previous >>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>> Should the keyListener also be set to null to free the >>>>>>>>>>>>>>>>> KeyHandler object? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() >>>>>>>>>>>>>>>>> && ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This check is used several times. It can be moved to a >>>>>>>>>>>>>>>>> separate method. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>>> 375 if (!(model instanceof DefaultButtonModel)) >>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = >>>>>>>>>>>>>>>>> (DefaultButtonModel) model; >>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null >>>>>>>>>>>>>>>>> model. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The curElement variable declaration could be moved >>>>>>>>>>>>>>>>> into the 'while' block. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put the >>>>>>>>>>>>>>>>> other code inside the 'if' block. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn == >>>>>>>>>>>>>>>>> null){ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>> second 'if' because it should already have true value. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The code that retrieves elements from a button group >>>>>>>>>>>>>>>>> is also used in the selectRadioButton() >>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and >>>>>>>>>>>>>>>>>> JCheckBox all passed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From dmitry.markov at oracle.com Fri Oct 3 05:58:33 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 03 Oct 2014 09:58:33 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <542905F4.8050200@oracle.com> References: <542905F4.8050200@oracle.com> Message-ID: <542E3B09.7070704@oracle.com> Hello, Friendly reminder... Could anyone review the fix, please? Thanks, Dmitry On 29/09/2014 11:10, dmitry markov wrote: > Hello, > > Could you review the fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8058120 > webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ > > Problem description: if some text (not wrapped by HTML tags) is > inserted via insertAfterEnd() method, the text is added directly to > the body of HTML document. This will cause incorrect representation of > added fragment. > Fix: it is necessary to detect the insertion of the text to the body > and wrap the text by p-implied tags. > > Thanks, > Dmitry From Sergey.Bylokhov at oracle.com Mon Oct 6 06:46:31 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 06 Oct 2014 10:46:31 +0400 Subject: [9] Review request for 8058305 BadLocationException is not thrown by javax.swing.text.View.getNextVisualPositionFrom() for invalid positions In-Reply-To: <54256284.80104@oracle.com> References: <542424AE.9060004@oracle.com> <54242EF8.4030601@oracle.com> <54256284.80104@oracle.com> Message-ID: <54323AC7.4020500@oracle.com> Hi, Alexander. The fix looks good. On 26.09.2014 16:56, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8058305/webrev.01 > > - the position check is added to the missed places > - the test is added > > Thanks, > Alexandr. > > On 9/25/2014 7:04 PM, Alexander Zvegintsev wrote: >> Hi Alexandr, >> >> We still don't throw a BadLocationException if component is not >> painted yet. >> (see BasicTextUI.getNextVisualPositionFrom() at 1121 line). >> This can be reproduced with sample code from the JBS issue. >> >> -- >> Thanks, >> Alexander. >> >> On 09/25/2014 06:20 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8058305 >>> webrev: http://cr.openjdk.java.net/~alexsch/8058305/webrev.00 >>> >>> According to the View.getNextVisualPositionFrom(...) method >>> javadoc >>> http://docs.oracle.com/javase/8/docs/api/javax/swing/text/View.html >>> the BadLocationException should be thrown if the given position is >>> not a valid position within the document >>> >>> The issue is covered by JCK tests. >>> >>> Thanks, >>> Alexandr. >>> >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Mon Oct 6 08:27:50 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 06 Oct 2014 12:27:50 +0400 Subject: [9] Review request for 8058305 BadLocationException is not thrown by javax.swing.text.View.getNextVisualPositionFrom() for invalid positions In-Reply-To: <54323AC7.4020500@oracle.com> References: <542424AE.9060004@oracle.com> <54242EF8.4030601@oracle.com> <54256284.80104@oracle.com> <54323AC7.4020500@oracle.com> Message-ID: <54325286.7030801@oracle.com> The fix looks good to me too. Thanks, Alexander. On 10/06/2014 10:46 AM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 26.09.2014 16:56, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8058305/webrev.01 >> >> - the position check is added to the missed places >> - the test is added >> >> Thanks, >> Alexandr. >> >> On 9/25/2014 7:04 PM, Alexander Zvegintsev wrote: >>> Hi Alexandr, >>> >>> We still don't throw a BadLocationException if component is not >>> painted yet. >>> (see BasicTextUI.getNextVisualPositionFrom() at 1121 line). >>> This can be reproduced with sample code from the JBS issue. >>> >>> -- >>> Thanks, >>> Alexander. >>> >>> On 09/25/2014 06:20 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058305 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8058305/webrev.00 >>>> >>>> According to the View.getNextVisualPositionFrom(...) method >>>> javadoc >>>> http://docs.oracle.com/javase/8/docs/api/javax/swing/text/View.html >>>> the BadLocationException should be thrown if the given position >>>> is not a valid position within the document >>>> >>>> The issue is covered by JCK tests. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> > > From alexander.zvegintsev at oracle.com Tue Oct 7 13:13:47 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 07 Oct 2014 17:13:47 +0400 Subject: [9] Review request for 8059297: Test api/javax_swing/interactive/JInternalFrameTests.html#JInternalFrame [JInternalFrameTest0007] fails with MotifLookAndFeel Message-ID: <5433E70B.8080607@oracle.com> Hello, please review a simple doc change: https://bugs.openjdk.java.net/browse/JDK-8059297 http://cr.openjdk.java.net/~azvegint/jdk/9/8059297/00/ CCC request will be filed after a technical review. -- Thanks, Alexander. From Sergey.Bylokhov at oracle.com Tue Oct 7 13:25:30 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Oct 2014 17:25:30 +0400 Subject: [9] Review request for 8059297: Test api/javax_swing/interactive/JInternalFrameTests.html#JInternalFrame [JInternalFrameTest0007] fails with MotifLookAndFeel In-Reply-To: <5433E70B.8080607@oracle.com> References: <5433E70B.8080607@oracle.com> Message-ID: <5433E9CA.70101@oracle.com> Hi, Alexander. The fix looks good. On 07.10.2014 17:13, Alexander Zvegintsev wrote: > Hello, > > please review a simple doc change: > https://bugs.openjdk.java.net/browse/JDK-8059297 > http://cr.openjdk.java.net/~azvegint/jdk/9/8059297/00/ > > CCC request will be filed after a technical review. > -- Best regards, Sergey. From vivi.an at oracle.com Wed Oct 8 05:45:20 2014 From: vivi.an at oracle.com (Vivi An) Date: Tue, 07 Oct 2014 22:45:20 -0700 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <542DC7A2.5000503@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> <542DC7A2.5000503@oracle.com> Message-ID: <5434CF70.10002@oracle.com> Hello Alexander, Latest patched is ready for review, test case is updated too: http://cr.openjdk.java.net/~van/8033699/webrev.07/ Thanks Vivi On 10/2/2014 2:46 PM, Vivi An wrote: > Thanks Alexander. Will look into it. > > Regards, > > ~ Vivi > > On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: >> Sorry, I wasn't clear, >> provided code with the "MIDDLE" button is just an example what user >> can write (pretty odd one btw) >> it is not in your tests. >> >> By lost functionality I mean that after this fix this user can't >> navigate to the "MIDDLE" button via keyboard >> (or to the btnEnd after ButtonGroup reordering). >> >> -- >> Thanks, >> Alexander. >> 02.10.2014 0:40, Vivi An wrote: >>> Thanks Alexander. >>> >>> I have some questions, please see comments inline. >>> >>> Regards, >>> >>> ~ Vivi >>> >>> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>>> Hello Vivi, >>>> >>>> the fix looks good to me in general, but we lost some functionality, >>> By functionality, you mean the functionality of the test, am I right? >>> >>>> here is some modified code from the previous version of the test: >>>> >>>> ButtonGroup btnGrp = new ButtonGroup(); >>>> btnGrp.add(radioBtn1); >>>> btnGrp.add(radioBtn2); >>>> btnGrp.add(radioBtn3); >>>> radioBtn1.setSelected(true); >>>> >>>> mainFrame.getContentPane().add(btnStart); >>>> mainFrame.getContentPane().add(radioBtn1); >>>> mainFrame.getContentPane().add(radioBtn2); >>>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>>> mainFrame.getContentPane().add(radioBtn3); >>>> mainFrame.getContentPane().add(btnEnd); >>> Just double checked the test in previous version and current >>> version, did not find a button "MIDDLE" like previous code snippet, >>> or I misunderstood, this is pseudo code? >>> Compare to the old test code, new changes made are: >>> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added to >>> a panel ("box" in below code snippet) and then to main frame, >>> border also added too to separate from new added non grouped single >>> radio button >>> 2) A single radio button (Not Grouped) is added to cover the bug >>> found in last round >>> 3) Tests 1- 6 are adjusted for preceding change to cover areas would >>> like to test >>> >>> Below is snippet from latest version, the "box" is the panel which >>> contains radio button group, a screenshot added too >>> 110 mainFrame.getContentPane().add(btnStart); >>> 111 mainFrame.getContentPane().add(box); >>> 112 mainFrame.getContentPane().add(radioBtnSingle); >>> 113 mainFrame.getContentPane().add(btnEnd); >>> >>> >>> >>>> >>>> After this fix we are not able to select "MIDDLE" button with a >>>> keyboard anymore. >>>> If we change ButtonGroup order to >>>> >>>> btnGrp.add(radioBtn3); >>>> btnGrp.add(radioBtn2); >>>> >>>> We get into a loop and we are unable to select btnEnd and all >>>> following components(Shift+Tab can help in that case). >>>> I think that these cases deserves some attention. >>>> >>>> -- >>>> Thanks, >>>> Alexander. >>>> >>>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>>> Hello Alexander, >>>>> >>>>> Thanks for the review. >>>>> >>>>> New patch is available under >>>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>>> >>>>> Regards, >>>>> >>>>> Vivi >>>>> >>>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>>> Hello Vivi, >>>>>> >>>>>> Since you are touching this code, could you please add missing >>>>>> @Override annotations? >>>>>> >>>>> Added >>>>>> void jumpToNextComponent(boolean next) { >>>>>> if (!getButtonGroupInfo()) >>>>>> return; >>>>>> >>>>>> This leads to an issue: we can't switch to a next component with >>>>>> a TAB key if JRadioButton >>>>>> is not in a ButtonGroup. (It may be a reason to write another test.) >>>>> Fixed >>>>>> >>>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>>>> ((JRadioButton) obj).isVisible() && >>>>>> ((JRadioButton) obj).isEnabled()); >>>>>> } >>>>> Fixed >>>>>> >>>>>> There is no need to do a null check before instanceof [1] >>>>>> >>>>>> * @param evt, the event object. >>>>>> * @param next, indicate if it's next one >>>>>> */ >>>>>> private void selectRadioButton(ActionEvent event, boolean >>>>>> next) { >>>>>> >>>>>> typo: evt should be event >>>>>> >>>>> Fixed >>>>>> >>>>>> I run the test and it fails at least on Linux. It happens due to >>>>>> a big auto delay: >>>>>> Robot holds key for too long so system sends TAB key multiple time. >>>>>> So I think auto delay should be about 100 ms. >>>>>> >>>>>> robot.setAutoDelay(300); >>>>>> >>>>>> It is enough to call it once after Robot creation, this will >>>>>> automatically add a 300 ms delay >>>>>> between Robot generated events (such as keyPress, mouseMove, etc). >>>>>> If you really want a delay between test runs please use >>>>>> Thread.sleep(). >>>>>> >>>>>> I see many calls to hitKey() and then to realSync(), so we can >>>>>> move realSync() call to the end of hitKey(). >>>>>> checkResult() may be combined with runTest(), hence we call one >>>>>> function instead of two. >>>>>> >>>>>> int sum = 0; >>>>>> for (int i = 0; i < testResults.length; i++) { >>>>>> if (testResults[i] == false) >>>>>> sum++; >>>>>> } >>>>>> >>>>>> if (sum != 0){ >>>>>> System.out.println("Total 5 tests, failed test(s): " >>>>>> + sum); >>>>>> throw new RuntimeException("Test failed."); >>>>>> } >>>>>> >>>>>> >>>>>> I don't think that this logic is applicable here, each test >>>>>> depends on previous: Test2 failure means that >>>>>> focus is on a wrong component, so all following tests will fail. >>>>>> BTW, this code is unreachable in case of test failure, since >>>>>> checkResult() already throws an exception. >>>>>> >>>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>>> >>>>> Test is updated, non-grouped radio button test is added, test >>>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Alexander. >>>>>> >>>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>>> Thank you Alexandr. >>>>>>> >>>>>>> Need one more review for this. Alexander, could you please take >>>>>>> a look at below fix? >>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Vivi >>>>>>> >>>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>>> Hello Alex, >>>>>>>>> >>>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>>> You are right. Fixed now. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>>> >>>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>> 537 // ... >>>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>>> 539 } >>>>>>>>>> 540 } else if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>> 548 // ... >>>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>>> 550 } >>>>>>>>>> >>>>>>>>>> The code in the if/else branches is almost the same except >>>>>>>>>> the true/false argument. >>>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>>> >>>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>> 510 if (next) >>>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>>> 512 >>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>>> 513 else >>>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>>> 515 >>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>>> >>>>>>>>>> This code can be also a little bit optimized: >>>>>>>>>> >>>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>>>>> firstBtn)); >>>>>>>>>> >>>>>>>>> It's different function call, one for focusNextComponent and >>>>>>>>> the other for focusPreviousComponent, not able to optimize in >>>>>>>>> suggested way. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Vivi >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you >>>>>>>>>>> >>>>>>>>>>> ~ Vivi >>>>>>>>>>> >>>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> I have missed one more case: >>>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>>> 538 } >>>>>>>>>>>> 539 >>>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>>>>> e.isShiftDown()) { >>>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>>> 550 } >>>>>>>>>>>> 551 } >>>>>>>>>>>> >>>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>>>> methods can be called. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All items addressed except last one, please see comments >>>>>>>>>>>>>>> inline. >>>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Should the first button be focused If next is true and >>>>>>>>>>>>>>>> last button is null? >>>>>>>>>>>>>>> Don't think last button could be null when this function >>>>>>>>>>>>>>> is triggered, last and first will always be set in case >>>>>>>>>>>>>>> there is at least one valid (enabled and visible) radio >>>>>>>>>>>>>>> button in the group. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to >>>>>>>>>>>>>>>>>>> next/previous >>>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>>> Should the keyListener also be set to null to free >>>>>>>>>>>>>>>>>> the KeyHandler object? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>>>>> 370 ((JRadioButton) >>>>>>>>>>>>>>>>>> eventSrc).isVisible() && ((JRadioButton) >>>>>>>>>>>>>>>>>> eventSrc).isEnabled())) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This check is used several times. It can be moved to >>>>>>>>>>>>>>>>>> a separate method. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>>>> 375 if (!(model instanceof DefaultButtonModel)) >>>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = >>>>>>>>>>>>>>>>>> (DefaultButtonModel) model; >>>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null >>>>>>>>>>>>>>>>>> model. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The curElement variable declaration could be moved >>>>>>>>>>>>>>>>>> into the 'while' block. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put >>>>>>>>>>>>>>>>>> the other code inside the 'if' block. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn >>>>>>>>>>>>>>>>>> == null){ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>>> second 'if' because it should already have true value. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The code that retrieves elements from a button group >>>>>>>>>>>>>>>>>> is also used in the selectRadioButton() >>>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and >>>>>>>>>>>>>>>>>>> JCheckBox all passed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From dmitry.markov at oracle.com Wed Oct 8 06:32:23 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 08 Oct 2014 10:32:23 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <542E3B09.7070704@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> Message-ID: <5434DA77.8020900@oracle.com> Hello, Any volunteers to review the fix? Thanks, Dmitry On 03/10/2014 09:58, dmitry markov wrote: > Hello, > > Friendly reminder... Could anyone review the fix, please? > > Thanks, > Dmitry > On 29/09/2014 11:10, dmitry markov wrote: >> Hello, >> >> Could you review the fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >> webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >> >> Problem description: if some text (not wrapped by HTML tags) is >> inserted via insertAfterEnd() method, the text is added directly to >> the body of HTML document. This will cause incorrect representation >> of added fragment. >> Fix: it is necessary to detect the insertion of the text to the body >> and wrap the text by p-implied tags. >> >> Thanks, >> Dmitry > From alexandr.scherbatiy at oracle.com Wed Oct 8 08:29:21 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 08 Oct 2014 12:29:21 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <5434DA77.8020900@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> <5434DA77.8020900@oracle.com> Message-ID: <5434F5E1.4050803@oracle.com> On 10/8/2014 10:32 AM, dmitry markov wrote: > Hello, > > Any volunteers to review the fix? Could you give more details about the change: ------------- - if (offset > getLength()) { + if (offset > (getLength() + 1)) { offset--; } ------------- Should it depend on the insertInBody value? Thanks, Alexandr. > > Thanks, > Dmitry > > On 03/10/2014 09:58, dmitry markov wrote: >> Hello, >> >> Friendly reminder... Could anyone review the fix, please? >> >> Thanks, >> Dmitry >> On 29/09/2014 11:10, dmitry markov wrote: >>> Hello, >>> >>> Could you review the fix for jdk9, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >>> >>> Problem description: if some text (not wrapped by HTML tags) is >>> inserted via insertAfterEnd() method, the text is added directly to >>> the body of HTML document. This will cause incorrect representation >>> of added fragment. >>> Fix: it is necessary to detect the insertion of the text to the body >>> and wrap the text by p-implied tags. >>> >>> Thanks, >>> Dmitry >> > From alexandr.scherbatiy at oracle.com Wed Oct 8 08:32:55 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 08 Oct 2014 12:32:55 +0400 Subject: [9] Review request for 8059297: Test api/javax_swing/interactive/JInternalFrameTests.html#JInternalFrame [JInternalFrameTest0007] fails with MotifLookAndFeel In-Reply-To: <5433E9CA.70101@oracle.com> References: <5433E70B.8080607@oracle.com> <5433E9CA.70101@oracle.com> Message-ID: <5434F6B7.1060703@oracle.com> The fix looks good to me. Thanks, Alexandr. On 10/7/2014 5:25 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 07.10.2014 17:13, Alexander Zvegintsev wrote: >> Hello, >> >> please review a simple doc change: >> https://bugs.openjdk.java.net/browse/JDK-8059297 >> http://cr.openjdk.java.net/~azvegint/jdk/9/8059297/00/ >> >> CCC request will be filed after a technical review. >> > > From dmitry.markov at oracle.com Wed Oct 8 10:08:25 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 08 Oct 2014 14:08:25 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <5434F5E1.4050803@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> <5434DA77.8020900@oracle.com> <5434F5E1.4050803@oracle.com> Message-ID: <54350D19.6010700@oracle.com> Hi Alexandr, Thank you for the review. HTMLDocument does not override getLength() method, so AbstractDocument.getLength() is used. AbstractDocument.getLength() returns one less than the length of the Content (see Java Docs for more details). So if we add anything to the end of the document, we can not position the caret before the inserted fragment without this change. I do not think it should depend on insertInBody value. Thanks, Dmitry On 08/10/2014 12:29, Alexander Scherbatiy wrote: > On 10/8/2014 10:32 AM, dmitry markov wrote: >> Hello, >> >> Any volunteers to review the fix? > > Could you give more details about the change: > ------------- > - if (offset > getLength()) { > + if (offset > (getLength() + 1)) { > offset--; > } > ------------- > > Should it depend on the insertInBody value? > > Thanks, > Alexandr. > >> >> Thanks, >> Dmitry >> >> On 03/10/2014 09:58, dmitry markov wrote: >>> Hello, >>> >>> Friendly reminder... Could anyone review the fix, please? >>> >>> Thanks, >>> Dmitry >>> On 29/09/2014 11:10, dmitry markov wrote: >>>> Hello, >>>> >>>> Could you review the fix for jdk9, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >>>> webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >>>> >>>> Problem description: if some text (not wrapped by HTML tags) is >>>> inserted via insertAfterEnd() method, the text is added directly to >>>> the body of HTML document. This will cause incorrect representation >>>> of added fragment. >>>> Fix: it is necessary to detect the insertion of the text to the >>>> body and wrap the text by p-implied tags. >>>> >>>> Thanks, >>>> Dmitry >>> >> > From alexey.ivanov at oracle.com Wed Oct 8 11:57:45 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 08 Oct 2014 15:57:45 +0400 Subject: [9] Review request for JDK-7170310: ScrollBar doesn't become active when tabs are created more than frame size Message-ID: <543526B9.3040707@oracle.com> Hello Swing team, Could you please review the fix for the bug: bug: https://bugs.openjdk.java.net/browse/JDK-7170310 webrev: http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.0/ Description: If you add more tabs to JTabbedPane than a frame can fit, scrolling buttons are not enabled, and users have no way to switch to hidden tabs until they click another tab. The test scenario is to add a new tab and select it right away. Root cause: Scrolling is not handled properly in this case because JTabbedPane.addTab invalidated the component. Method setSelectedIndex scrolls the active tab into view but the location of the new added tab is not available yet. The fix: Invalidate the view of JViewport to ensure its size is set to its preferred size during validation. Then stateChanged listener ensures the layout is valid before scrolling the tabs view. I created a new automatic test for this issue. I ran all JTabbedPane regression tests and they passed. Thank you in advance, Alexey. From alexandr.scherbatiy at oracle.com Wed Oct 8 12:04:50 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 08 Oct 2014 16:04:50 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <54350D19.6010700@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> <5434DA77.8020900@oracle.com> <5434F5E1.4050803@oracle.com> <54350D19.6010700@oracle.com> Message-ID: <54352862.6060708@oracle.com> The fix looks good to me. Could you also test the fix with the JCK and regression tests? Thanks, Alexandr. On 10/8/2014 2:08 PM, dmitry markov wrote: > Hi Alexandr, > > Thank you for the review. > > HTMLDocument does not override getLength() method, so > AbstractDocument.getLength() is used. AbstractDocument.getLength() > returns one less than the length of the Content (see Java Docs for > more details). So if we add anything to the end of the document, we > can not position the caret before the inserted fragment without this > change. I do not think it should depend on insertInBody value. > > Thanks, > Dmitry > On 08/10/2014 12:29, Alexander Scherbatiy wrote: >> On 10/8/2014 10:32 AM, dmitry markov wrote: >>> Hello, >>> >>> Any volunteers to review the fix? >> >> Could you give more details about the change: >> ------------- >> - if (offset > getLength()) { >> + if (offset > (getLength() + 1)) { >> offset--; >> } >> ------------- >> >> Should it depend on the insertInBody value? >> >> Thanks, >> Alexandr. >> >>> >>> Thanks, >>> Dmitry >>> >>> On 03/10/2014 09:58, dmitry markov wrote: >>>> Hello, >>>> >>>> Friendly reminder... Could anyone review the fix, please? >>>> >>>> Thanks, >>>> Dmitry >>>> On 29/09/2014 11:10, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix for jdk9, please? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >>>>> >>>>> Problem description: if some text (not wrapped by HTML tags) is >>>>> inserted via insertAfterEnd() method, the text is added directly >>>>> to the body of HTML document. This will cause incorrect >>>>> representation of added fragment. >>>>> Fix: it is necessary to detect the insertion of the text to the >>>>> body and wrap the text by p-implied tags. >>>>> >>>>> Thanks, >>>>> Dmitry >>>> >>> >> > From alexander.zvegintsev at oracle.com Wed Oct 8 18:36:09 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 08 Oct 2014 22:36:09 +0400 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <5434CF70.10002@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> <542DC7A2.5000503@oracle.com> <5434CF70.10002@oracle.com> Message-ID: <54358419.4000006@oracle.com> Hello Vivi, getFocusTransferBaseComponent(): Window parentWnd = SwingUtilities.getWindowAncestor((Component) activeBtn); if (parentWnd instanceof Container) { Container container = (Container)parentWnd; Window extending Container class, hence there is no need to use instanceof, null check is enough here. container variable is redundant here, you may reuse parentWnd. There are many redundant class casts in this function. Also I suggest to use ternary operator to increase readability. Something like this: Component getFocusTransferBaseComponent(boolean next) { Component focusBaseComp = activeBtn; Window container = SwingUtilities.getWindowAncestor(activeBtn); if (container != null) { FocusTraversalPolicy policy = container.getFocusTraversalPolicy(); Component comp = next ? policy.getComponentAfter(container, activeBtn) : policy.getComponentBefore(container, activeBtn); // If next component in the button group, use last/first button as base focus // otherwise, use the activeButton as the base focus if (containsInGroup(comp)) { focusBaseComp = next ? lastBtn : firstBtn; } } return focusBaseComp; } Small typo in test: Seperate - > Separate (2 times) -- Thanks, Alexander. On 10/08/2014 09:45 AM, Vivi An wrote: > Hello Alexander, > > Latest patched is ready for review, test case is updated too: > http://cr.openjdk.java.net/~van/8033699/webrev.07/ > > Thanks > > Vivi > > On 10/2/2014 2:46 PM, Vivi An wrote: >> Thanks Alexander. Will look into it. >> >> Regards, >> >> ~ Vivi >> >> On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: >>> Sorry, I wasn't clear, >>> provided code with the "MIDDLE" button is just an example what user >>> can write (pretty odd one btw) >>> it is not in your tests. >>> >>> By lost functionality I mean that after this fix this user can't >>> navigate to the "MIDDLE" button via keyboard >>> (or to the btnEnd after ButtonGroup reordering). >>> >>> -- >>> Thanks, >>> Alexander. >>> 02.10.2014 0:40, Vivi An wrote: >>>> Thanks Alexander. >>>> >>>> I have some questions, please see comments inline. >>>> >>>> Regards, >>>> >>>> ~ Vivi >>>> >>>> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>>>> Hello Vivi, >>>>> >>>>> the fix looks good to me in general, but we lost some functionality, >>>> By functionality, you mean the functionality of the test, am I right? >>>> >>>>> here is some modified code from the previous version of the test: >>>>> >>>>> ButtonGroup btnGrp = new ButtonGroup(); >>>>> btnGrp.add(radioBtn1); >>>>> btnGrp.add(radioBtn2); >>>>> btnGrp.add(radioBtn3); >>>>> radioBtn1.setSelected(true); >>>>> >>>>> mainFrame.getContentPane().add(btnStart); >>>>> mainFrame.getContentPane().add(radioBtn1); >>>>> mainFrame.getContentPane().add(radioBtn2); >>>>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>>>> mainFrame.getContentPane().add(radioBtn3); >>>>> mainFrame.getContentPane().add(btnEnd); >>>> Just double checked the test in previous version and current >>>> version, did not find a button "MIDDLE" like previous code >>>> snippet, or I misunderstood, this is pseudo code? >>>> Compare to the old test code, new changes made are: >>>> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added >>>> to a panel ("box" in below code snippet) and then to main frame, >>>> border also added too to separate from new added non grouped single >>>> radio button >>>> 2) A single radio button (Not Grouped) is added to cover the bug >>>> found in last round >>>> 3) Tests 1- 6 are adjusted for preceding change to cover areas >>>> would like to test >>>> >>>> Below is snippet from latest version, the "box" is the panel which >>>> contains radio button group, a screenshot added too >>>> 110 mainFrame.getContentPane().add(btnStart); >>>> 111 mainFrame.getContentPane().add(box); >>>> 112 mainFrame.getContentPane().add(radioBtnSingle); >>>> 113 mainFrame.getContentPane().add(btnEnd); >>>> >>>> >>>> >>>>> >>>>> After this fix we are not able to select "MIDDLE" button with a >>>>> keyboard anymore. >>>>> If we change ButtonGroup order to >>>>> >>>>> btnGrp.add(radioBtn3); >>>>> btnGrp.add(radioBtn2); >>>>> >>>>> We get into a loop and we are unable to select btnEnd and all >>>>> following components(Shift+Tab can help in that case). >>>>> I think that these cases deserves some attention. >>>>> >>>>> -- >>>>> Thanks, >>>>> Alexander. >>>>> >>>>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>>>> Hello Alexander, >>>>>> >>>>>> Thanks for the review. >>>>>> >>>>>> New patch is available under >>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivi >>>>>> >>>>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>>>> Hello Vivi, >>>>>>> >>>>>>> Since you are touching this code, could you please add missing >>>>>>> @Override annotations? >>>>>>> >>>>>> Added >>>>>>> void jumpToNextComponent(boolean next) { >>>>>>> if (!getButtonGroupInfo()) >>>>>>> return; >>>>>>> >>>>>>> This leads to an issue: we can't switch to a next component with >>>>>>> a TAB key if JRadioButton >>>>>>> is not in a ButtonGroup. (It may be a reason to write another >>>>>>> test.) >>>>>> Fixed >>>>>>> >>>>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>>>>> ((JRadioButton) obj).isVisible() && >>>>>>> ((JRadioButton) obj).isEnabled()); >>>>>>> } >>>>>> Fixed >>>>>>> >>>>>>> There is no need to do a null check before instanceof [1] >>>>>>> >>>>>>> * @param evt, the event object. >>>>>>> * @param next, indicate if it's next one >>>>>>> */ >>>>>>> private void selectRadioButton(ActionEvent event, boolean >>>>>>> next) { >>>>>>> >>>>>>> typo: evt should be event >>>>>>> >>>>>> Fixed >>>>>>> >>>>>>> I run the test and it fails at least on Linux. It happens due to >>>>>>> a big auto delay: >>>>>>> Robot holds key for too long so system sends TAB key multiple time. >>>>>>> So I think auto delay should be about 100 ms. >>>>>>> >>>>>>> robot.setAutoDelay(300); >>>>>>> >>>>>>> It is enough to call it once after Robot creation, this will >>>>>>> automatically add a 300 ms delay >>>>>>> between Robot generated events (such as keyPress, mouseMove, etc). >>>>>>> If you really want a delay between test runs please use >>>>>>> Thread.sleep(). >>>>>>> >>>>>>> I see many calls to hitKey() and then to realSync(), so we can >>>>>>> move realSync() call to the end of hitKey(). >>>>>>> checkResult() may be combined with runTest(), hence we call one >>>>>>> function instead of two. >>>>>>> >>>>>>> int sum = 0; >>>>>>> for (int i = 0; i < testResults.length; i++) { >>>>>>> if (testResults[i] == false) >>>>>>> sum++; >>>>>>> } >>>>>>> >>>>>>> if (sum != 0){ >>>>>>> System.out.println("Total 5 tests, failed test(s): " >>>>>>> + sum); >>>>>>> throw new RuntimeException("Test failed."); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> I don't think that this logic is applicable here, each test >>>>>>> depends on previous: Test2 failure means that >>>>>>> focus is on a wrong component, so all following tests will fail. >>>>>>> BTW, this code is unreachable in case of test failure, since >>>>>>> checkResult() already throws an exception. >>>>>>> >>>>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>>>> >>>>>> Test is updated, non-grouped radio button test is added, test >>>>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Alexander. >>>>>>> >>>>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>>>> Thank you Alexandr. >>>>>>>> >>>>>>>> Need one more review for this. Alexander, could you please take >>>>>>>> a look at below fix? >>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Vivi >>>>>>>> >>>>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The fix looks good to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>>>> Hello Alex, >>>>>>>>>> >>>>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>>>> You are right. Fixed now. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>> 537 // ... >>>>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>>>> 539 } >>>>>>>>>>> 540 } else if (e.getKeyCode() == >>>>>>>>>>> KeyEvent.VK_TAB) { >>>>>>>>>>> 548 // ... >>>>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>>>> 550 } >>>>>>>>>>> >>>>>>>>>>> The code in the if/else branches is almost the same except >>>>>>>>>>> the true/false argument. >>>>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>>>> >>>>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>> 510 if (next) >>>>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>>>> 512 >>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>>>> 513 else >>>>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>>>> 515 >>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>>>> >>>>>>>>>>> This code can be also a little bit optimized: >>>>>>>>>>> >>>>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn >>>>>>>>>>> : firstBtn)); >>>>>>>>>>> >>>>>>>>>> It's different function call, one for focusNextComponent and >>>>>>>>>> the other for focusPreviousComponent, not able to optimize in >>>>>>>>>> suggested way. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Vivi >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> >>>>>>>>>>>> ~ Vivi >>>>>>>>>>>> >>>>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I have missed one more case: >>>>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>>>> 538 } >>>>>>>>>>>>> 539 >>>>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>>>>>> e.isShiftDown()) { >>>>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>>>> 550 } >>>>>>>>>>>>> 551 } >>>>>>>>>>>>> >>>>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>>>>> methods can be called. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All items addressed except last one, please see >>>>>>>>>>>>>>>> comments inline. >>>>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Should the first button be focused If next is true and >>>>>>>>>>>>>>>>> last button is null? >>>>>>>>>>>>>>>> Don't think last button could be null when this >>>>>>>>>>>>>>>> function is triggered, last and first will always be >>>>>>>>>>>>>>>> set in case there is at least one valid (enabled and >>>>>>>>>>>>>>>> visible) radio button in the group. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved >>>>>>>>>>>>>>>>>>>> to next/previous >>>>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>>>> Should the keyListener also be set to null to free >>>>>>>>>>>>>>>>>>> the KeyHandler object? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() && >>>>>>>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This check is used several times. It can be moved to >>>>>>>>>>>>>>>>>>> a separate method. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>>>>> 375 if (!(model instanceof >>>>>>>>>>>>>>>>>>> DefaultButtonModel)) >>>>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = (DefaultButtonModel) >>>>>>>>>>>>>>>>>>> model; >>>>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for >>>>>>>>>>>>>>>>>>> null model. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The curElement variable declaration could be moved >>>>>>>>>>>>>>>>>>> into the 'while' block. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put >>>>>>>>>>>>>>>>>>> the other code inside the 'if' block. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn >>>>>>>>>>>>>>>>>>> == null){ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>>>> second 'if' because it should already have true value. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The code that retrieves elements from a button group >>>>>>>>>>>>>>>>>>> is also used in the selectRadioButton() >>>>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton >>>>>>>>>>>>>>>>>>>> and JCheckBox all passed. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From vivi.an at oracle.com Thu Oct 9 05:53:43 2014 From: vivi.an at oracle.com (Vivi An) Date: Wed, 08 Oct 2014 22:53:43 -0700 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <54358419.4000006@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> <542DC7A2.5000503@oracle.com> <5434CF70.10002@oracle.com> <54358419.4000006@oracle.com> Message-ID: <543622E7.4060309@oracle.com> Thank you Alexander, New patch with fix: http://cr.openjdk.java.net/~van/8033699/webrev.08/ Regards, Vivi On 10/8/2014 11:36 AM, Alexander Zvegintsev wrote: > Hello Vivi, > > getFocusTransferBaseComponent(): > Window parentWnd = SwingUtilities.getWindowAncestor((Component) activeBtn); > if (parentWnd instanceof Container) { > Container container = (Container)parentWnd; > Window extending Container class, hence there is no need to use > instanceof, null > check is enough here. container variable is redundant here, you may > reuse parentWnd. > There are many redundant class casts in this function. > Also I suggest to use ternary operator to increase readability. > > Something like this: > > Component getFocusTransferBaseComponent(boolean next) { > Component focusBaseComp = activeBtn; > Window container = > SwingUtilities.getWindowAncestor(activeBtn); > if (container != null) { > FocusTraversalPolicy policy = > container.getFocusTraversalPolicy(); > Component comp = next > ? policy.getComponentAfter(container, activeBtn) > : policy.getComponentBefore(container, activeBtn); > > // If next component in the button group, use > last/first button as base focus > // otherwise, use the activeButton as the base focus > if (containsInGroup(comp)) { > focusBaseComp = next ? lastBtn : firstBtn; > } > } > > return focusBaseComp; > } > > Small typo in test: Seperate - > Separate (2 times) > > -- > Thanks, > Alexander. > On 10/08/2014 09:45 AM, Vivi An wrote: >> Hello Alexander, >> >> Latest patched is ready for review, test case is updated too: >> http://cr.openjdk.java.net/~van/8033699/webrev.07/ >> >> Thanks >> >> Vivi >> >> On 10/2/2014 2:46 PM, Vivi An wrote: >>> Thanks Alexander. Will look into it. >>> >>> Regards, >>> >>> ~ Vivi >>> >>> On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: >>>> Sorry, I wasn't clear, >>>> provided code with the "MIDDLE" button is just an example what user >>>> can write (pretty odd one btw) >>>> it is not in your tests. >>>> >>>> By lost functionality I mean that after this fix this user can't >>>> navigate to the "MIDDLE" button via keyboard >>>> (or to the btnEnd after ButtonGroup reordering). >>>> >>>> -- >>>> Thanks, >>>> Alexander. >>>> 02.10.2014 0:40, Vivi An wrote: >>>>> Thanks Alexander. >>>>> >>>>> I have some questions, please see comments inline. >>>>> >>>>> Regards, >>>>> >>>>> ~ Vivi >>>>> >>>>> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>>>>> Hello Vivi, >>>>>> >>>>>> the fix looks good to me in general, but we lost some functionality, >>>>> By functionality, you mean the functionality of the test, am I right? >>>>> >>>>>> here is some modified code from the previous version of the test: >>>>>> >>>>>> ButtonGroup btnGrp = new ButtonGroup(); >>>>>> btnGrp.add(radioBtn1); >>>>>> btnGrp.add(radioBtn2); >>>>>> btnGrp.add(radioBtn3); >>>>>> radioBtn1.setSelected(true); >>>>>> >>>>>> mainFrame.getContentPane().add(btnStart); >>>>>> mainFrame.getContentPane().add(radioBtn1); >>>>>> mainFrame.getContentPane().add(radioBtn2); >>>>>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>>>>> mainFrame.getContentPane().add(radioBtn3); >>>>>> mainFrame.getContentPane().add(btnEnd); >>>>> Just double checked the test in previous version and current >>>>> version, did not find a button "MIDDLE" like previous code >>>>> snippet, or I misunderstood, this is pseudo code? >>>>> Compare to the old test code, new changes made are: >>>>> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added >>>>> to a panel ("box" in below code snippet) and then to main frame, >>>>> border also added too to separate from new added non grouped >>>>> single radio button >>>>> 2) A single radio button (Not Grouped) is added to cover the bug >>>>> found in last round >>>>> 3) Tests 1- 6 are adjusted for preceding change to cover areas >>>>> would like to test >>>>> >>>>> Below is snippet from latest version, the "box" is the panel which >>>>> contains radio button group, a screenshot added too >>>>> 110 mainFrame.getContentPane().add(btnStart); >>>>> 111 mainFrame.getContentPane().add(box); >>>>> 112 mainFrame.getContentPane().add(radioBtnSingle); >>>>> 113 mainFrame.getContentPane().add(btnEnd); >>>>> >>>>> >>>>> >>>>>> >>>>>> After this fix we are not able to select "MIDDLE" button with a >>>>>> keyboard anymore. >>>>>> If we change ButtonGroup order to >>>>>> >>>>>> btnGrp.add(radioBtn3); >>>>>> btnGrp.add(radioBtn2); >>>>>> >>>>>> We get into a loop and we are unable to select btnEnd and all >>>>>> following components(Shift+Tab can help in that case). >>>>>> I think that these cases deserves some attention. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Alexander. >>>>>> >>>>>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>>>>> Hello Alexander, >>>>>>> >>>>>>> Thanks for the review. >>>>>>> >>>>>>> New patch is available under >>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Vivi >>>>>>> >>>>>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>>>>> Hello Vivi, >>>>>>>> >>>>>>>> Since you are touching this code, could you please add missing >>>>>>>> @Override annotations? >>>>>>>> >>>>>>> Added >>>>>>>> void jumpToNextComponent(boolean next) { >>>>>>>> if (!getButtonGroupInfo()) >>>>>>>> return; >>>>>>>> >>>>>>>> This leads to an issue: we can't switch to a next component >>>>>>>> with a TAB key if JRadioButton >>>>>>>> is not in a ButtonGroup. (It may be a reason to write another >>>>>>>> test.) >>>>>>> Fixed >>>>>>>> >>>>>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>>>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>>>>>> ((JRadioButton) obj).isVisible() && >>>>>>>> ((JRadioButton) obj).isEnabled()); >>>>>>>> } >>>>>>> Fixed >>>>>>>> >>>>>>>> There is no need to do a null check before instanceof [1] >>>>>>>> >>>>>>>> * @param evt, the event object. >>>>>>>> * @param next, indicate if it's next one >>>>>>>> */ >>>>>>>> private void selectRadioButton(ActionEvent event, boolean >>>>>>>> next) { >>>>>>>> >>>>>>>> typo: evt should be event >>>>>>>> >>>>>>> Fixed >>>>>>>> >>>>>>>> I run the test and it fails at least on Linux. It happens due >>>>>>>> to a big auto delay: >>>>>>>> Robot holds key for too long so system sends TAB key multiple >>>>>>>> time. >>>>>>>> So I think auto delay should be about 100 ms. >>>>>>>> >>>>>>>> robot.setAutoDelay(300); >>>>>>>> >>>>>>>> It is enough to call it once after Robot creation, this will >>>>>>>> automatically add a 300 ms delay >>>>>>>> between Robot generated events (such as keyPress, mouseMove, etc). >>>>>>>> If you really want a delay between test runs please use >>>>>>>> Thread.sleep(). >>>>>>>> >>>>>>>> I see many calls to hitKey() and then to realSync(), so we can >>>>>>>> move realSync() call to the end of hitKey(). >>>>>>>> checkResult() may be combined with runTest(), hence we call one >>>>>>>> function instead of two. >>>>>>>> >>>>>>>> int sum = 0; >>>>>>>> for (int i = 0; i < testResults.length; i++) { >>>>>>>> if (testResults[i] == false) >>>>>>>> sum++; >>>>>>>> } >>>>>>>> >>>>>>>> if (sum != 0){ >>>>>>>> System.out.println("Total 5 tests, failed test(s): >>>>>>>> " + sum); >>>>>>>> throw new RuntimeException("Test failed."); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> I don't think that this logic is applicable here, each test >>>>>>>> depends on previous: Test2 failure means that >>>>>>>> focus is on a wrong component, so all following tests will fail. >>>>>>>> BTW, this code is unreachable in case of test failure, since >>>>>>>> checkResult() already throws an exception. >>>>>>>> >>>>>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>>>>> >>>>>>> Test is updated, non-grouped radio button test is added, test >>>>>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Alexander. >>>>>>>> >>>>>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>>>>> Thank you Alexandr. >>>>>>>>> >>>>>>>>> Need one more review for this. Alexander, could you please >>>>>>>>> take a look at below fix? >>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Vivi >>>>>>>>> >>>>>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> The fix looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>>>>> Hello Alex, >>>>>>>>>>> >>>>>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>>>>> You are right. Fixed now. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>> 537 // ... >>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>>>>> 539 } >>>>>>>>>>>> 540 } else if (e.getKeyCode() == >>>>>>>>>>>> KeyEvent.VK_TAB) { >>>>>>>>>>>> 548 // ... >>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>>>>> 550 } >>>>>>>>>>>> >>>>>>>>>>>> The code in the if/else branches is almost the same >>>>>>>>>>>> except the true/false argument. >>>>>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>>>>> >>>>>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> >>>>>>>>>>>> 510 if (next) >>>>>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>>>>> 512 >>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>>>>> 513 else >>>>>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>>>>> 515 >>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>>>>> >>>>>>>>>>>> This code can be also a little bit optimized: >>>>>>>>>>>> >>>>>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn >>>>>>>>>>>> : firstBtn)); >>>>>>>>>>>> >>>>>>>>>>> It's different function call, one for focusNextComponent >>>>>>>>>>> and the other for focusPreviousComponent, not able to >>>>>>>>>>> optimize in suggested way. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Vivi >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you >>>>>>>>>>>>> >>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have missed one more case: >>>>>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>>>>> 538 } >>>>>>>>>>>>>> 539 >>>>>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB && >>>>>>>>>>>>>> e.isShiftDown()) { >>>>>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>>>>> 550 } >>>>>>>>>>>>>> 551 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>>>>>> methods can be called. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> All items addressed except last one, please see >>>>>>>>>>>>>>>>> comments inline. >>>>>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you remove spaces in the brackets? After code >>>>>>>>>>>>>>>> formatting it should be "if (keyListener != null) {" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != null) >>>>>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Should the first button be focused If next is true >>>>>>>>>>>>>>>>>> and last button is null? >>>>>>>>>>>>>>>>> Don't think last button could be null when this >>>>>>>>>>>>>>>>> function is triggered, last and first will always be >>>>>>>>>>>>>>>>> set in case there is at least one valid (enabled and >>>>>>>>>>>>>>>>> visible) radio button in the group. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved >>>>>>>>>>>>>>>>>>>>> to next/previous >>>>>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change >>>>>>>>>>>>>>>>>>>>> selection inside >>>>>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>>>>> Should the keyListener also be set to null to free >>>>>>>>>>>>>>>>>>>> the KeyHandler object? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof JRadioButton && >>>>>>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() && >>>>>>>>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This check is used several times. It can be moved >>>>>>>>>>>>>>>>>>>> to a separate method. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>>>>>> 375 if (!(model instanceof >>>>>>>>>>>>>>>>>>>> DefaultButtonModel)) >>>>>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = (DefaultButtonModel) >>>>>>>>>>>>>>>>>>>> model; >>>>>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for >>>>>>>>>>>>>>>>>>>> null model. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The curElement variable declaration could be >>>>>>>>>>>>>>>>>>>> moved into the 'while' block. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put >>>>>>>>>>>>>>>>>>>> the other code inside the 'if' block. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>>>>> 422 } else if (srcFound && nextBtn >>>>>>>>>>>>>>>>>>>> == null){ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>>>>> second 'if' because it should already have true value. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The code that retrieves elements from a button >>>>>>>>>>>>>>>>>>>> group is also used in the selectRadioButton() >>>>>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton >>>>>>>>>>>>>>>>>>>>> and JCheckBox all passed. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From dmitry.markov at oracle.com Thu Oct 9 08:08:20 2014 From: dmitry.markov at oracle.com (dmitry markov) Date: Thu, 09 Oct 2014 12:08:20 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <54352862.6060708@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> <5434DA77.8020900@oracle.com> <5434F5E1.4050803@oracle.com> <54350D19.6010700@oracle.com> <54352862.6060708@oracle.com> Message-ID: <54364274.8030402@oracle.com> I ran related JCK and regression tests and did not observe any failures. Thanks, Dmitry On 08/10/2014 16:04, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Could you also test the fix with the JCK and regression tests? > > Thanks, > Alexandr. > > On 10/8/2014 2:08 PM, dmitry markov wrote: >> Hi Alexandr, >> >> Thank you for the review. >> >> HTMLDocument does not override getLength() method, so >> AbstractDocument.getLength() is used. AbstractDocument.getLength() >> returns one less than the length of the Content (see Java Docs for >> more details). So if we add anything to the end of the document, we >> can not position the caret before the inserted fragment without this >> change. I do not think it should depend on insertInBody value. >> >> Thanks, >> Dmitry >> On 08/10/2014 12:29, Alexander Scherbatiy wrote: >>> On 10/8/2014 10:32 AM, dmitry markov wrote: >>>> Hello, >>>> >>>> Any volunteers to review the fix? >>> >>> Could you give more details about the change: >>> ------------- >>> - if (offset > getLength()) { >>> + if (offset > (getLength() + 1)) { >>> offset--; >>> } >>> ------------- >>> >>> Should it depend on the insertInBody value? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 03/10/2014 09:58, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Friendly reminder... Could anyone review the fix, please? >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> On 29/09/2014 11:10, dmitry markov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review the fix for jdk9, please? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >>>>>> >>>>>> Problem description: if some text (not wrapped by HTML tags) is >>>>>> inserted via insertAfterEnd() method, the text is added directly >>>>>> to the body of HTML document. This will cause incorrect >>>>>> representation of added fragment. >>>>>> Fix: it is necessary to detect the insertion of the text to the >>>>>> body and wrap the text by p-implied tags. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>> >>>> >>> >> > From alexander.zvegintsev at oracle.com Thu Oct 9 09:52:49 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 09 Oct 2014 13:52:49 +0400 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <543622E7.4060309@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> <542DC7A2.5000503@oracle.com> <5434CF70.10002@oracle.com> <54358419.4000006@oracle.com> <543622E7.4060309@oracle.com> Message-ID: <54365AF1.3090603@oracle.com> Hello Vivi We can move Hashset creation to btnsInGroup's declaration, thus the following lines can be removed 460 if (btnsInGroup == null) 461 btnsInGroup = new HashSet(); Otherwise the fix looks good to me. Thanks, Alexander. On 10/09/2014 09:53 AM, Vivi An wrote: > Thank you Alexander, > > New patch with fix: > http://cr.openjdk.java.net/~van/8033699/webrev.08/ > > Regards, > > Vivi > > On 10/8/2014 11:36 AM, Alexander Zvegintsev wrote: >> Hello Vivi, >> >> getFocusTransferBaseComponent(): >> Window parentWnd = SwingUtilities.getWindowAncestor((Component) activeBtn); >> if (parentWnd instanceof Container) { >> Container container = (Container)parentWnd; >> Window extending Container class, hence there is no need to use >> instanceof, null >> check is enough here. container variable is redundant here, you may >> reuse parentWnd. >> There are many redundant class casts in this function. >> Also I suggest to use ternary operator to increase readability. >> >> Something like this: >> >> Component getFocusTransferBaseComponent(boolean next) { >> Component focusBaseComp = activeBtn; >> Window container = >> SwingUtilities.getWindowAncestor(activeBtn); >> if (container != null) { >> FocusTraversalPolicy policy = >> container.getFocusTraversalPolicy(); >> Component comp = next >> ? policy.getComponentAfter(container, activeBtn) >> : policy.getComponentBefore(container, >> activeBtn); >> >> // If next component in the button group, use >> last/first button as base focus >> // otherwise, use the activeButton as the base focus >> if (containsInGroup(comp)) { >> focusBaseComp = next ? lastBtn : firstBtn; >> } >> } >> >> return focusBaseComp; >> } >> >> Small typo in test: Seperate - > Separate (2 times) >> >> -- >> Thanks, >> Alexander. >> On 10/08/2014 09:45 AM, Vivi An wrote: >>> Hello Alexander, >>> >>> Latest patched is ready for review, test case is updated too: >>> http://cr.openjdk.java.net/~van/8033699/webrev.07/ >>> >>> Thanks >>> >>> Vivi >>> >>> On 10/2/2014 2:46 PM, Vivi An wrote: >>>> Thanks Alexander. Will look into it. >>>> >>>> Regards, >>>> >>>> ~ Vivi >>>> >>>> On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: >>>>> Sorry, I wasn't clear, >>>>> provided code with the "MIDDLE" button is just an example what >>>>> user can write (pretty odd one btw) >>>>> it is not in your tests. >>>>> >>>>> By lost functionality I mean that after this fix this user can't >>>>> navigate to the "MIDDLE" button via keyboard >>>>> (or to the btnEnd after ButtonGroup reordering). >>>>> >>>>> -- >>>>> Thanks, >>>>> Alexander. >>>>> 02.10.2014 0:40, Vivi An wrote: >>>>>> Thanks Alexander. >>>>>> >>>>>> I have some questions, please see comments inline. >>>>>> >>>>>> Regards, >>>>>> >>>>>> ~ Vivi >>>>>> >>>>>> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>>>>>> Hello Vivi, >>>>>>> >>>>>>> the fix looks good to me in general, but we lost some >>>>>>> functionality, >>>>>> By functionality, you mean the functionality of the test, am I >>>>>> right? >>>>>> >>>>>>> here is some modified code from the previous version of the test: >>>>>>> >>>>>>> ButtonGroup btnGrp = new ButtonGroup(); >>>>>>> btnGrp.add(radioBtn1); >>>>>>> btnGrp.add(radioBtn2); >>>>>>> btnGrp.add(radioBtn3); >>>>>>> radioBtn1.setSelected(true); >>>>>>> >>>>>>> mainFrame.getContentPane().add(btnStart); >>>>>>> mainFrame.getContentPane().add(radioBtn1); >>>>>>> mainFrame.getContentPane().add(radioBtn2); >>>>>>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>>>>>> mainFrame.getContentPane().add(radioBtn3); >>>>>>> mainFrame.getContentPane().add(btnEnd); >>>>>> Just double checked the test in previous version and current >>>>>> version, did not find a button "MIDDLE" like previous code >>>>>> snippet, or I misunderstood, this is pseudo code? >>>>>> Compare to the old test code, new changes made are: >>>>>> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) added >>>>>> to a panel ("box" in below code snippet) and then to main frame, >>>>>> border also added too to separate from new added non grouped >>>>>> single radio button >>>>>> 2) A single radio button (Not Grouped) is added to cover the bug >>>>>> found in last round >>>>>> 3) Tests 1- 6 are adjusted for preceding change to cover areas >>>>>> would like to test >>>>>> >>>>>> Below is snippet from latest version, the "box" is the panel >>>>>> which contains radio button group, a screenshot added too >>>>>> 110 mainFrame.getContentPane().add(btnStart); >>>>>> 111 mainFrame.getContentPane().add(box); >>>>>> 112 mainFrame.getContentPane().add(radioBtnSingle); >>>>>> 113 mainFrame.getContentPane().add(btnEnd); >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> After this fix we are not able to select "MIDDLE" button with a >>>>>>> keyboard anymore. >>>>>>> If we change ButtonGroup order to >>>>>>> >>>>>>> btnGrp.add(radioBtn3); >>>>>>> btnGrp.add(radioBtn2); >>>>>>> >>>>>>> We get into a loop and we are unable to select btnEnd and all >>>>>>> following components(Shift+Tab can help in that case). >>>>>>> I think that these cases deserves some attention. >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Alexander. >>>>>>> >>>>>>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>>>>>> Hello Alexander, >>>>>>>> >>>>>>>> Thanks for the review. >>>>>>>> >>>>>>>> New patch is available under >>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Vivi >>>>>>>> >>>>>>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>>>>>> Hello Vivi, >>>>>>>>> >>>>>>>>> Since you are touching this code, could you please add missing >>>>>>>>> @Override annotations? >>>>>>>>> >>>>>>>> Added >>>>>>>>> void jumpToNextComponent(boolean next) { >>>>>>>>> if (!getButtonGroupInfo()) >>>>>>>>> return; >>>>>>>>> >>>>>>>>> This leads to an issue: we can't switch to a next component >>>>>>>>> with a TAB key if JRadioButton >>>>>>>>> is not in a ButtonGroup. (It may be a reason to write another >>>>>>>>> test.) >>>>>>>> Fixed >>>>>>>>> >>>>>>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>>>>>> return ((obj != null) && (obj instanceof JRadioButton) && >>>>>>>>> ((JRadioButton) obj).isVisible() && >>>>>>>>> ((JRadioButton) obj).isEnabled()); >>>>>>>>> } >>>>>>>> Fixed >>>>>>>>> >>>>>>>>> There is no need to do a null check before instanceof [1] >>>>>>>>> >>>>>>>>> * @param evt, the event object. >>>>>>>>> * @param next, indicate if it's next one >>>>>>>>> */ >>>>>>>>> private void selectRadioButton(ActionEvent event, boolean >>>>>>>>> next) { >>>>>>>>> >>>>>>>>> typo: evt should be event >>>>>>>>> >>>>>>>> Fixed >>>>>>>>> >>>>>>>>> I run the test and it fails at least on Linux. It happens due >>>>>>>>> to a big auto delay: >>>>>>>>> Robot holds key for too long so system sends TAB key multiple >>>>>>>>> time. >>>>>>>>> So I think auto delay should be about 100 ms. >>>>>>>>> >>>>>>>>> robot.setAutoDelay(300); >>>>>>>>> >>>>>>>>> It is enough to call it once after Robot creation, this will >>>>>>>>> automatically add a 300 ms delay >>>>>>>>> between Robot generated events (such as keyPress, mouseMove, >>>>>>>>> etc). >>>>>>>>> If you really want a delay between test runs please use >>>>>>>>> Thread.sleep(). >>>>>>>>> >>>>>>>>> I see many calls to hitKey() and then to realSync(), so we can >>>>>>>>> move realSync() call to the end of hitKey(). >>>>>>>>> checkResult() may be combined with runTest(), hence we call >>>>>>>>> one function instead of two. >>>>>>>>> >>>>>>>>> int sum = 0; >>>>>>>>> for (int i = 0; i < testResults.length; i++) { >>>>>>>>> if (testResults[i] == false) >>>>>>>>> sum++; >>>>>>>>> } >>>>>>>>> >>>>>>>>> if (sum != 0){ >>>>>>>>> System.out.println("Total 5 tests, failed test(s): >>>>>>>>> " + sum); >>>>>>>>> throw new RuntimeException("Test failed."); >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't think that this logic is applicable here, each test >>>>>>>>> depends on previous: Test2 failure means that >>>>>>>>> focus is on a wrong component, so all following tests will fail. >>>>>>>>> BTW, this code is unreachable in case of test failure, since >>>>>>>>> checkResult() already throws an exception. >>>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>>>>>> >>>>>>>> Test is updated, non-grouped radio button test is added, test >>>>>>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks, >>>>>>>>> Alexander. >>>>>>>>> >>>>>>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>>>>>> Thank you Alexandr. >>>>>>>>>> >>>>>>>>>> Need one more review for this. Alexander, could you please >>>>>>>>>> take a look at below fix? >>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Vivi >>>>>>>>>> >>>>>>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> The fix looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>>>>>> Hello Alex, >>>>>>>>>>>> >>>>>>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>>>>>> You are right. Fixed now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>>>>>> 529 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>> 537 // ... >>>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>>>>>> 539 } >>>>>>>>>>>>> 540 } else if (e.getKeyCode() == >>>>>>>>>>>>> KeyEvent.VK_TAB) { >>>>>>>>>>>>> 548 // ... >>>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>>>>>> 550 } >>>>>>>>>>>>> >>>>>>>>>>>>> The code in the if/else branches is almost the same >>>>>>>>>>>>> except the true/false argument. >>>>>>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>>>>>> >>>>>>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>> Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> 510 if (next) >>>>>>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>>>>>> 512 >>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>>>>>> 513 else >>>>>>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>>>>>> 515 >>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>>>>>> >>>>>>>>>>>>> This code can be also a little bit optimized: >>>>>>>>>>>>> >>>>>>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>>>>>>>> firstBtn)); >>>>>>>>>>>>> >>>>>>>>>>>> It's different function call, one for focusNextComponent >>>>>>>>>>>> and the other for focusPreviousComponent, not able to >>>>>>>>>>>> optimize in suggested way. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Vivi >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>> >>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have missed one more case: >>>>>>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>>>>>> 538 } >>>>>>>>>>>>>>> 539 >>>>>>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB >>>>>>>>>>>>>>> && e.isShiftDown()) { >>>>>>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>>>>>> 550 } >>>>>>>>>>>>>>> 551 } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) >>>>>>>>>>>>>>> methods can be called. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All items addressed except last one, please see >>>>>>>>>>>>>>>>>> comments inline. >>>>>>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you remove spaces in the brackets? After >>>>>>>>>>>>>>>>> code formatting it should be "if (keyListener != null) {" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != >>>>>>>>>>>>>>>>>>> null) >>>>>>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should the first button be focused If next is true >>>>>>>>>>>>>>>>>>> and last button is null? >>>>>>>>>>>>>>>>>> Don't think last button could be null when this >>>>>>>>>>>>>>>>>> function is triggered, last and first will always be >>>>>>>>>>>>>>>>>> set in case there is at least one valid (enabled and >>>>>>>>>>>>>>>>>> visible) radio button in the group. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved >>>>>>>>>>>>>>>>>>>>>> to next/previous >>>>>>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to >>>>>>>>>>>>>>>>>>>>>> change selection inside >>>>>>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>>>>>> Should the keyListener also be set to null to free >>>>>>>>>>>>>>>>>>>>> the KeyHandler object? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof >>>>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() && >>>>>>>>>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This check is used several times. It can be moved >>>>>>>>>>>>>>>>>>>>> to a separate method. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 373 // Get the button model from the source. >>>>>>>>>>>>>>>>>>>>> 374 ButtonModel model = ((AbstractButton) >>>>>>>>>>>>>>>>>>>>> eventSrc).getModel(); >>>>>>>>>>>>>>>>>>>>> 375 if (!(model instanceof >>>>>>>>>>>>>>>>>>>>> DefaultButtonModel)) >>>>>>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = (DefaultButtonModel) >>>>>>>>>>>>>>>>>>>>> model; >>>>>>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for >>>>>>>>>>>>>>>>>>>>> null model. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The curElement variable declaration could be >>>>>>>>>>>>>>>>>>>>> moved into the 'while' block. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not put >>>>>>>>>>>>>>>>>>>>> the other code inside the 'if' block. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>>>>>> 422 } else if (srcFound && >>>>>>>>>>>>>>>>>>>>> nextBtn == null){ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>>>>>> second 'if' because it should already have true >>>>>>>>>>>>>>>>>>>>> value. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The code that retrieves elements from a button >>>>>>>>>>>>>>>>>>>>> group is also used in the selectRadioButton() >>>>>>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton >>>>>>>>>>>>>>>>>>>>>> and JCheckBox all passed. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From alexander.potochkin at oracle.com Thu Oct 9 11:32:45 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 09 Oct 2014 15:32:45 +0400 Subject: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument In-Reply-To: <54364274.8030402@oracle.com> References: <542905F4.8050200@oracle.com> <542E3B09.7070704@oracle.com> <5434DA77.8020900@oracle.com> <5434F5E1.4050803@oracle.com> <54350D19.6010700@oracle.com> <54352862.6060708@oracle.com> <54364274.8030402@oracle.com> Message-ID: <5436725D.5080107@oracle.com> Hello Dmitry Looks good! Thanks alexp On 10/9/2014 12:08 PM, dmitry markov wrote: > I ran related JCK and regression tests and did not observe any failures. > > Thanks, > Dmitry > On 08/10/2014 16:04, Alexander Scherbatiy wrote: >> >> The fix looks good to me. >> >> Could you also test the fix with the JCK and regression tests? >> >> Thanks, >> Alexandr. >> >> On 10/8/2014 2:08 PM, dmitry markov wrote: >>> Hi Alexandr, >>> >>> Thank you for the review. >>> >>> HTMLDocument does not override getLength() method, so >>> AbstractDocument.getLength() is used. AbstractDocument.getLength() >>> returns one less than the length of the Content (see Java Docs for >>> more details). So if we add anything to the end of the document, we >>> can not position the caret before the inserted fragment without this >>> change. I do not think it should depend on insertInBody value. >>> >>> Thanks, >>> Dmitry >>> On 08/10/2014 12:29, Alexander Scherbatiy wrote: >>>> On 10/8/2014 10:32 AM, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Any volunteers to review the fix? >>>> >>>> Could you give more details about the change: >>>> ------------- >>>> - if (offset > getLength()) { >>>> + if (offset > (getLength() + 1)) { >>>> offset--; >>>> } >>>> ------------- >>>> >>>> Should it depend on the insertInBody value? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> On 03/10/2014 09:58, dmitry markov wrote: >>>>>> Hello, >>>>>> >>>>>> Friendly reminder... Could anyone review the fix, please? >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> On 29/09/2014 11:10, dmitry markov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix for jdk9, please? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058120 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ >>>>>>> >>>>>>> Problem description: if some text (not wrapped by HTML tags) is >>>>>>> inserted via insertAfterEnd() method, the text is added directly >>>>>>> to the body of HTML document. This will cause incorrect >>>>>>> representation of added fragment. >>>>>>> Fix: it is necessary to detect the insertion of the text to the >>>>>>> body and wrap the text by p-implied tags. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>> >>>>> >>>> >>> >> > From alexey.ivanov at oracle.com Thu Oct 9 12:07:40 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 09 Oct 2014 16:07:40 +0400 Subject: [9] Review request for JDK-7170310: ScrollBar doesn't become active when tabs are created more than frame size In-Reply-To: <543526B9.3040707@oracle.com> References: <543526B9.3040707@oracle.com> Message-ID: <54367A8C.6070304@oracle.com> Hello Swing team, A small update to the test: I explicitly set look-and-feel to MetalLookAndFeel. Updated webrev: http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.1/ Thanks, Alexey. On 08.10.2014 15:57, Alexey Ivanov wrote: > Hello Swing team, > > Could you please review the fix for the bug: > bug: https://bugs.openjdk.java.net/browse/JDK-7170310 > webrev: http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.0/ > > Description: > If you add more tabs to JTabbedPane than a frame can fit, scrolling > buttons are not enabled, and users have no way to switch to hidden > tabs until they click another tab. > > The test scenario is to add a new tab and select it right away. > > Root cause: > Scrolling is not handled properly in this case because > JTabbedPane.addTab invalidated the component. Method setSelectedIndex > scrolls the active tab into view but the location of the new added tab > is not available yet. > > The fix: > Invalidate the view of JViewport to ensure its size is set to its > preferred size during validation. Then stateChanged listener ensures > the layout is valid before scrolling the tabs view. > > I created a new automatic test for this issue. > I ran all JTabbedPane regression tests and they passed. > > Thank you in advance, > Alexey. From alexander.potochkin at oracle.com Thu Oct 9 12:26:11 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 09 Oct 2014 16:26:11 +0400 Subject: [9] Review request for JDK-7170310: ScrollBar doesn't become active when tabs are created more than frame size In-Reply-To: <54367A8C.6070304@oracle.com> References: <543526B9.3040707@oracle.com> <54367A8C.6070304@oracle.com> Message-ID: <54367EE3.8060604@oracle.com> Hello Alexey The fix looks good Thanks alexp On 10/9/2014 4:07 PM, Alexey Ivanov wrote: > Hello Swing team, > > A small update to the test: I explicitly set look-and-feel to > MetalLookAndFeel. > > Updated webrev: > http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.1/ > > Thanks, > Alexey. > > On 08.10.2014 15:57, Alexey Ivanov wrote: >> Hello Swing team, >> >> Could you please review the fix for the bug: >> bug: https://bugs.openjdk.java.net/browse/JDK-7170310 >> webrev: http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.0/ >> >> Description: >> If you add more tabs to JTabbedPane than a frame can fit, scrolling >> buttons are not enabled, and users have no way to switch to hidden >> tabs until they click another tab. >> >> The test scenario is to add a new tab and select it right away. >> >> Root cause: >> Scrolling is not handled properly in this case because >> JTabbedPane.addTab invalidated the component. Method setSelectedIndex >> scrolls the active tab into view but the location of the new added >> tab is not available yet. >> >> The fix: >> Invalidate the view of JViewport to ensure its size is set to its >> preferred size during validation. Then stateChanged listener ensures >> the layout is valid before scrolling the tabs view. >> >> I created a new automatic test for this issue. >> I ran all JTabbedPane regression tests and they passed. >> >> Thank you in advance, >> Alexey. > From alexandr.scherbatiy at oracle.com Thu Oct 9 14:12:23 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 09 Oct 2014 18:12:23 +0400 Subject: [9] Review request for JDK-7170310: ScrollBar doesn't become active when tabs are created more than frame size In-Reply-To: <54367A8C.6070304@oracle.com> References: <543526B9.3040707@oracle.com> <54367A8C.6070304@oracle.com> Message-ID: <543697C7.4020206@oracle.com> The fix looks good to me. Thanks, Alexandr. On 10/9/2014 4:07 PM, Alexey Ivanov wrote: > Hello Swing team, > > A small update to the test: I explicitly set look-and-feel to > MetalLookAndFeel. > > Updated webrev: > http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.1/ > > Thanks, > Alexey. > > On 08.10.2014 15:57, Alexey Ivanov wrote: >> Hello Swing team, >> >> Could you please review the fix for the bug: >> bug: https://bugs.openjdk.java.net/browse/JDK-7170310 >> webrev: http://cr.openjdk.java.net/~aivanov/7170310/jdk9/webrev.0/ >> >> Description: >> If you add more tabs to JTabbedPane than a frame can fit, scrolling >> buttons are not enabled, and users have no way to switch to hidden >> tabs until they click another tab. >> >> The test scenario is to add a new tab and select it right away. >> >> Root cause: >> Scrolling is not handled properly in this case because >> JTabbedPane.addTab invalidated the component. Method setSelectedIndex >> scrolls the active tab into view but the location of the new added >> tab is not available yet. >> >> The fix: >> Invalidate the view of JViewport to ensure its size is set to its >> preferred size during validation. Then stateChanged listener ensures >> the layout is valid before scrolling the tabs view. >> >> I created a new automatic test for this issue. >> I ran all JTabbedPane regression tests and they passed. >> >> Thank you in advance, >> Alexey. > From vivi.an at oracle.com Thu Oct 9 16:13:11 2014 From: vivi.an at oracle.com (Vivi An) Date: Thu, 09 Oct 2014 09:13:11 -0700 Subject: [9] Review request for 8033699: Incorrect radio button behavior In-Reply-To: <54365AF1.3090603@oracle.com> References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com> <5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com> <541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com> <5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com> <5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com> <541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com> <541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com> <542B1D67.1030400@oracle.com> <542BF7CC.5020409@oracle.com> <542C66B1.90500@oracle.com> <542CFCA1.5050008@oracle.com> <542DC7A2.5000503@oracle.com> <5434CF70.10002@oracle.com> <54358419.4000006@oracle.com> <543622E7.4060309@oracle.com> <54365AF1.3090603@oracle.com> Message-ID: <5436B417.2060900@oracle.com> Thanks Alexander. Will make the fix. Regards, Vivi On 10/9/2014 2:52 AM, Alexander Zvegintsev wrote: > Hello Vivi > > We can move Hashset creation to btnsInGroup's declaration, thus the > following lines can be removed > 460 if (btnsInGroup == null) > 461 btnsInGroup = new HashSet(); > > Otherwise the fix looks good to me. > Thanks, > > Alexander. > On 10/09/2014 09:53 AM, Vivi An wrote: >> Thank you Alexander, >> >> New patch with fix: >> http://cr.openjdk.java.net/~van/8033699/webrev.08/ >> >> Regards, >> >> Vivi >> >> On 10/8/2014 11:36 AM, Alexander Zvegintsev wrote: >>> Hello Vivi, >>> >>> getFocusTransferBaseComponent(): >>> Window parentWnd = SwingUtilities.getWindowAncestor((Component) activeBtn); >>> if (parentWnd instanceof Container) { >>> Container container = (Container)parentWnd; >>> Window extending Container class, hence there is no need to use >>> instanceof, null >>> check is enough here. container variable is redundant here, you may >>> reuse parentWnd. >>> There are many redundant class casts in this function. >>> Also I suggest to use ternary operator to increase readability. >>> >>> Something like this: >>> >>> Component getFocusTransferBaseComponent(boolean next) { >>> Component focusBaseComp = activeBtn; >>> Window container = >>> SwingUtilities.getWindowAncestor(activeBtn); >>> if (container != null) { >>> FocusTraversalPolicy policy = >>> container.getFocusTraversalPolicy(); >>> Component comp = next >>> ? policy.getComponentAfter(container, activeBtn) >>> : policy.getComponentBefore(container, >>> activeBtn); >>> >>> // If next component in the button group, use >>> last/first button as base focus >>> // otherwise, use the activeButton as the base focus >>> if (containsInGroup(comp)) { >>> focusBaseComp = next ? lastBtn : firstBtn; >>> } >>> } >>> >>> return focusBaseComp; >>> } >>> >>> Small typo in test: Seperate - > Separate (2 times) >>> >>> -- >>> Thanks, >>> Alexander. >>> On 10/08/2014 09:45 AM, Vivi An wrote: >>>> Hello Alexander, >>>> >>>> Latest patched is ready for review, test case is updated too: >>>> http://cr.openjdk.java.net/~van/8033699/webrev.07/ >>>> >>>> Thanks >>>> >>>> Vivi >>>> >>>> On 10/2/2014 2:46 PM, Vivi An wrote: >>>>> Thanks Alexander. Will look into it. >>>>> >>>>> Regards, >>>>> >>>>> ~ Vivi >>>>> >>>>> On 10/2/2014 12:20 AM, Alexander Zvegintsev wrote: >>>>>> Sorry, I wasn't clear, >>>>>> provided code with the "MIDDLE" button is just an example what >>>>>> user can write (pretty odd one btw) >>>>>> it is not in your tests. >>>>>> >>>>>> By lost functionality I mean that after this fix this user can't >>>>>> navigate to the "MIDDLE" button via keyboard >>>>>> (or to the btnEnd after ButtonGroup reordering). >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Alexander. >>>>>> 02.10.2014 0:40, Vivi An wrote: >>>>>>> Thanks Alexander. >>>>>>> >>>>>>> I have some questions, please see comments inline. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> ~ Vivi >>>>>>> >>>>>>> On 10/1/2014 5:47 AM, Alexander Zvegintsev wrote: >>>>>>>> Hello Vivi, >>>>>>>> >>>>>>>> the fix looks good to me in general, but we lost some >>>>>>>> functionality, >>>>>>> By functionality, you mean the functionality of the test, am I >>>>>>> right? >>>>>>> >>>>>>>> here is some modified code from the previous version of the test: >>>>>>>> >>>>>>>> ButtonGroup btnGrp = new ButtonGroup(); >>>>>>>> btnGrp.add(radioBtn1); >>>>>>>> btnGrp.add(radioBtn2); >>>>>>>> btnGrp.add(radioBtn3); >>>>>>>> radioBtn1.setSelected(true); >>>>>>>> >>>>>>>> mainFrame.getContentPane().add(btnStart); >>>>>>>> mainFrame.getContentPane().add(radioBtn1); >>>>>>>> mainFrame.getContentPane().add(radioBtn2); >>>>>>>> mainFrame.getContentPane().add(new JButton("MIDDLE")); >>>>>>>> mainFrame.getContentPane().add(radioBtn3); >>>>>>>> mainFrame.getContentPane().add(btnEnd); >>>>>>> Just double checked the test in previous version and current >>>>>>> version, did not find a button "MIDDLE" like previous code >>>>>>> snippet, or I misunderstood, this is pseudo code? >>>>>>> Compare to the old test code, new changes made are: >>>>>>> 1) Radio button group( radioBtn1, radioBtn2 and radioBtn1 ) >>>>>>> added to a panel ("box" in below code snippet) and then to main >>>>>>> frame, border also added too to separate from new added non >>>>>>> grouped single radio button >>>>>>> 2) A single radio button (Not Grouped) is added to cover the bug >>>>>>> found in last round >>>>>>> 3) Tests 1- 6 are adjusted for preceding change to cover areas >>>>>>> would like to test >>>>>>> >>>>>>> Below is snippet from latest version, the "box" is the panel >>>>>>> which contains radio button group, a screenshot added too >>>>>>> 110 mainFrame.getContentPane().add(btnStart); >>>>>>> 111 mainFrame.getContentPane().add(box); >>>>>>> 112 mainFrame.getContentPane().add(radioBtnSingle); >>>>>>> 113 mainFrame.getContentPane().add(btnEnd); >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> After this fix we are not able to select "MIDDLE" button with a >>>>>>>> keyboard anymore. >>>>>>>> If we change ButtonGroup order to >>>>>>>> >>>>>>>> btnGrp.add(radioBtn3); >>>>>>>> btnGrp.add(radioBtn2); >>>>>>>> >>>>>>>> We get into a loop and we are unable to select btnEnd and all >>>>>>>> following components(Shift+Tab can help in that case). >>>>>>>> I think that these cases deserves some attention. >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Alexander. >>>>>>>> >>>>>>>> On 10/01/2014 01:15 AM, Vivi An wrote: >>>>>>>>> Hello Alexander, >>>>>>>>> >>>>>>>>> Thanks for the review. >>>>>>>>> >>>>>>>>> New patch is available under >>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.06/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Vivi >>>>>>>>> >>>>>>>>> On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote: >>>>>>>>>> Hello Vivi, >>>>>>>>>> >>>>>>>>>> Since you are touching this code, could you please add >>>>>>>>>> missing @Override annotations? >>>>>>>>>> >>>>>>>>> Added >>>>>>>>>> void jumpToNextComponent(boolean next) { >>>>>>>>>> if (!getButtonGroupInfo()) >>>>>>>>>> return; >>>>>>>>>> >>>>>>>>>> This leads to an issue: we can't switch to a next component >>>>>>>>>> with a TAB key if JRadioButton >>>>>>>>>> is not in a ButtonGroup. (It may be a reason to write another >>>>>>>>>> test.) >>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>> private boolean isValidRadioButtonObj(Object obj) { >>>>>>>>>> return ((obj != null) && (obj instanceof >>>>>>>>>> JRadioButton) && >>>>>>>>>> ((JRadioButton) obj).isVisible() && >>>>>>>>>> ((JRadioButton) obj).isEnabled()); >>>>>>>>>> } >>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>> There is no need to do a null check before instanceof [1] >>>>>>>>>> >>>>>>>>>> * @param evt, the event object. >>>>>>>>>> * @param next, indicate if it's next one >>>>>>>>>> */ >>>>>>>>>> private void selectRadioButton(ActionEvent event, boolean >>>>>>>>>> next) { >>>>>>>>>> >>>>>>>>>> typo: evt should be event >>>>>>>>>> >>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>> I run the test and it fails at least on Linux. It happens due >>>>>>>>>> to a big auto delay: >>>>>>>>>> Robot holds key for too long so system sends TAB key multiple >>>>>>>>>> time. >>>>>>>>>> So I think auto delay should be about 100 ms. >>>>>>>>>> >>>>>>>>>> robot.setAutoDelay(300); >>>>>>>>>> >>>>>>>>>> It is enough to call it once after Robot creation, this will >>>>>>>>>> automatically add a 300 ms delay >>>>>>>>>> between Robot generated events (such as keyPress, mouseMove, >>>>>>>>>> etc). >>>>>>>>>> If you really want a delay between test runs please use >>>>>>>>>> Thread.sleep(). >>>>>>>>>> >>>>>>>>>> I see many calls to hitKey() and then to realSync(), so we >>>>>>>>>> can move realSync() call to the end of hitKey(). >>>>>>>>>> checkResult() may be combined with runTest(), hence we call >>>>>>>>>> one function instead of two. >>>>>>>>>> >>>>>>>>>> int sum = 0; >>>>>>>>>> for (int i = 0; i < testResults.length; i++) { >>>>>>>>>> if (testResults[i] == false) >>>>>>>>>> sum++; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if (sum != 0){ >>>>>>>>>> System.out.println("Total 5 tests, failed >>>>>>>>>> test(s): " + sum); >>>>>>>>>> throw new RuntimeException("Test failed."); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think that this logic is applicable here, each test >>>>>>>>>> depends on previous: Test2 failure means that >>>>>>>>>> focus is on a wrong component, so all following tests will fail. >>>>>>>>>> BTW, this code is unreachable in case of test failure, since >>>>>>>>>> checkResult() already throws an exception. >>>>>>>>>> >>>>>>>>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2 >>>>>>>>>> >>>>>>>>> Test is updated, non-grouped radio button test is added, test >>>>>>>>> passed on Oracle Linux 5 u6 32 bits and Windows 7. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks, >>>>>>>>>> Alexander. >>>>>>>>>> >>>>>>>>>> On 09/18/2014 09:23 PM, Vivi An wrote: >>>>>>>>>>> Thank you Alexandr. >>>>>>>>>>> >>>>>>>>>>> Need one more review for this. Alexander, could you please >>>>>>>>>>> take a look at below fix? >>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Vivi >>>>>>>>>>> >>>>>>>>>>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> The fix looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 9/18/2014 3:09 AM, Vivi An wrote: >>>>>>>>>>>>> Hello Alex, >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 9/17/2014 9:17 AM, Vivi An wrote: >>>>>>>>>>>>>>> You are right. Fixed now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 528 if (e.isShiftDown()) { >>>>>>>>>>>>>> 529 if (e.getKeyCode() == >>>>>>>>>>>>>> KeyEvent.VK_TAB) { >>>>>>>>>>>>>> 537 // ... >>>>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(false); >>>>>>>>>>>>>> 539 } >>>>>>>>>>>>>> 540 } else if (e.getKeyCode() == >>>>>>>>>>>>>> KeyEvent.VK_TAB) { >>>>>>>>>>>>>> 548 // ... >>>>>>>>>>>>>> btnGroupInfo.jumpToNextComponent(true); >>>>>>>>>>>>>> 550 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> The code in the if/else branches is almost the same >>>>>>>>>>>>>> except the true/false argument. >>>>>>>>>>>>>> I would suggest to unify them in the following way: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>>> // ... jumpToNextComponent(!e.isShiftDown()) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 510 if (next) >>>>>>>>>>>>>> 511 KeyboardFocusManager. >>>>>>>>>>>>>> 512 >>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn); >>>>>>>>>>>>>> 513 else >>>>>>>>>>>>>> 514 KeyboardFocusManager. >>>>>>>>>>>>>> 515 >>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn); >>>>>>>>>>>>>> >>>>>>>>>>>>>> This code can be also a little bit optimized: >>>>>>>>>>>>>> >>>>>>>>>>>>>> KeyboardFocusManager.getCurrentKeyboardFocusManager(). >>>>>>>>>>>>>> focusPreviousComponent((JComponent) (next ? lastBtn : >>>>>>>>>>>>>> firstBtn)); >>>>>>>>>>>>>> >>>>>>>>>>>>> It's different function call, one for focusNextComponent >>>>>>>>>>>>> and the other for focusPreviousComponent, not able to >>>>>>>>>>>>> optimize in suggested way. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Vivi >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have missed one more case: >>>>>>>>>>>>>>>> 527 public void keyPressed(KeyEvent e) { >>>>>>>>>>>>>>>> 528 if (e.getKeyCode() == KeyEvent.VK_TAB) { >>>>>>>>>>>>>>>> // jumpToNextComponent(true) >>>>>>>>>>>>>>>> 538 } >>>>>>>>>>>>>>>> 539 >>>>>>>>>>>>>>>> 540 if (e.getKeyCode() == KeyEvent.VK_TAB >>>>>>>>>>>>>>>> && e.isShiftDown()) { >>>>>>>>>>>>>>>> //jumpToNextComponent(false) >>>>>>>>>>>>>>>> 550 } >>>>>>>>>>>>>>>> 551 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that if e.isShiftDown() is true then both >>>>>>>>>>>>>>>> jumpToNextComponent(true) and >>>>>>>>>>>>>>>> jumpToNextComponent(false) methods can be called. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote: >>>>>>>>>>>>>>>>> Fixed. New Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Alex. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>> Thanks Alexander. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> All items addressed except last one, please see >>>>>>>>>>>>>>>>>>> comments inline. >>>>>>>>>>>>>>>>>>> New Webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.02/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 163 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you remove spaces in the brackets? After >>>>>>>>>>>>>>>>>> code formatting it should be "if (keyListener != >>>>>>>>>>>>>>>>>> null) {" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 543 if (next && btnGroupInfo.lastBtn != null) >>>>>>>>>>>>>>>>>>>> 544 KeyboardFocusManager. >>>>>>>>>>>>>>>>>>>> 545 >>>>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn); >>>>>>>>>>>>>>>>>>>> 546 else if (btnGroupInfo.firstBtn != >>>>>>>>>>>>>>>>>>>> null) >>>>>>>>>>>>>>>>>>>> 547 KeyboardFocusManager. >>>>>>>>>>>>>>>>>>>> 548 >>>>>>>>>>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn); >>>>>>>>>>>>>>>>>>>> 549 } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Should the first button be focused If next is true >>>>>>>>>>>>>>>>>>>> and last button is null? >>>>>>>>>>>>>>>>>>> Don't think last button could be null when this >>>>>>>>>>>>>>>>>>> function is triggered, last and first will always be >>>>>>>>>>>>>>>>>>> set in case there is at least one valid (enabled and >>>>>>>>>>>>>>>>>>> visible) radio button in the group. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It seems that lastBtn != null and firstBtn != null >>>>>>>>>>>>>>>>>> checks are not necessary in this case. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ~ Vivi >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote: >>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made: >>>>>>>>>>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus >>>>>>>>>>>>>>>>>>>>>>> moved to next/previous >>>>>>>>>>>>>>>>>>>>>>> component outside of the radio button group >>>>>>>>>>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to >>>>>>>>>>>>>>>>>>>>>>> change selection inside >>>>>>>>>>>>>>>>>>>>>>> radio button group >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 56 private KeyListener keyListener = null; >>>>>>>>>>>>>>>>>>>>>> 57 private KeyHandler handler = null; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It seems that these both fields point to the same >>>>>>>>>>>>>>>>>>>>>> object. Is it possible to get rid of one of them? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 152 if ( keyListener != null ) { >>>>>>>>>>>>>>>>>>>>>> 153 button.removeKeyListener( keyListener ); >>>>>>>>>>>>>>>>>>>>>> 154 } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Some UIs also set the listener to null in the >>>>>>>>>>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like >>>>>>>>>>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI). >>>>>>>>>>>>>>>>>>>>>> Should the keyListener also be set to null to >>>>>>>>>>>>>>>>>>>>>> free the KeyHandler object? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 369 if (!(eventSrc instanceof >>>>>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>>>>> 370 ((JRadioButton) eventSrc).isVisible() && >>>>>>>>>>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled())) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This check is used several times. It can be moved >>>>>>>>>>>>>>>>>>>>>> to a separate method. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 373 // Get the button model from the >>>>>>>>>>>>>>>>>>>>>> source. >>>>>>>>>>>>>>>>>>>>>> 374 ButtonModel model = >>>>>>>>>>>>>>>>>>>>>> ((AbstractButton) eventSrc).getModel(); >>>>>>>>>>>>>>>>>>>>>> 375 if (!(model instanceof >>>>>>>>>>>>>>>>>>>>>> DefaultButtonModel)) >>>>>>>>>>>>>>>>>>>>>> 376 return; >>>>>>>>>>>>>>>>>>>>>> 377 >>>>>>>>>>>>>>>>>>>>>> 378 // If the button model is >>>>>>>>>>>>>>>>>>>>>> DefaultButtonModel, and use it, otherwise return. >>>>>>>>>>>>>>>>>>>>>> 379 DefaultButtonModel bm = (DefaultButtonModel) >>>>>>>>>>>>>>>>>>>>>> model; >>>>>>>>>>>>>>>>>>>>>> 380 if (bm == null) >>>>>>>>>>>>>>>>>>>>>> 381 return; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The second check is not necessary because (model >>>>>>>>>>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for >>>>>>>>>>>>>>>>>>>>>> null model. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 404 AbstractButton curElement = null; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The curElement variable declaration could be >>>>>>>>>>>>>>>>>>>>>> moved into the 'while' block. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 408 if (curElement instanceof >>>>>>>>>>>>>>>>>>>>>> JRadioButton && >>>>>>>>>>>>>>>>>>>>>> 409 ((JRadioButton) curElement).isVisible() && >>>>>>>>>>>>>>>>>>>>>> 410 ((JRadioButton) curElement).isEnabled()){ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It is possible to use 'continue' here to not >>>>>>>>>>>>>>>>>>>>>> put the other code inside the 'if' block. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 418 else if (!srcFound){ >>>>>>>>>>>>>>>>>>>>>> 422 } else if (srcFound && >>>>>>>>>>>>>>>>>>>>>> nextBtn == null){ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It is not necessary to check the srcFound in the >>>>>>>>>>>>>>>>>>>>>> second 'if' because it should already have true >>>>>>>>>>>>>>>>>>>>>> value. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 444 if (newSelectedBtn != null){ >>>>>>>>>>>>>>>>>>>>>> 445 newSelectedBtn.requestFocusInWindow(); >>>>>>>>>>>>>>>>>>>>>> 446 newSelectedBtn.setSelected(true); >>>>>>>>>>>>>>>>>>>>>> 447 } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 522 private void >>>>>>>>>>>>>>>>>>>>>> jumpToNextComponent(JRadioButton btn, boolean next){ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The code that retrieves elements from a button >>>>>>>>>>>>>>>>>>>>>> group is also used in the selectRadioButton() >>>>>>>>>>>>>>>>>>>>>> and can be moved to a separate method. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton >>>>>>>>>>>>>>>>>>>>>>> and JCheckBox all passed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Vivi >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32466 bytes Desc: not available URL: From Sergey.Bylokhov at oracle.com Fri Oct 10 08:28:32 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Oct 2014 12:28:32 +0400 Subject: [9] Review Request: 8059943 [macosx] Aqua LaF should use BI.TYPE_INT_ARGB_PRE for a better performance Message-ID: <543798B0.3090203@oracle.com> Hello. Please review the small fix for jdk 9. Only TYPE_INT_ARGB_PRE is natively supported on osx in opengl pipeline(see OGLBlitLoops.java). Other types with alpha use OGLGeneralBlit which convert an image to argb_pre on the fly, this hurts a performance. Bug: https://bugs.openjdk.java.net/browse/JDK-8059943 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059943/webrev.00 -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Oct 10 09:58:41 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 10 Oct 2014 13:58:41 +0400 Subject: [9] Review Request: 8059943 [macosx] Aqua LaF should use BI.TYPE_INT_ARGB_PRE for a better performance In-Reply-To: <543798B0.3090203@oracle.com> References: <543798B0.3090203@oracle.com> Message-ID: <5437ADD1.5020305@oracle.com> The fix looks good to me. Is it possible to write an automated test for the fix? Thanks, Alexandr. On 10/10/2014 12:28 PM, Sergey Bylokhov wrote: > Hello. > Please review the small fix for jdk 9. > Only TYPE_INT_ARGB_PRE is natively supported on osx in opengl > pipeline(see OGLBlitLoops.java). Other types with alpha use > OGLGeneralBlit which convert an image to argb_pre on the fly, this > hurts a performance. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059943 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8059943/webrev.00 > From Sergey.Bylokhov at oracle.com Fri Oct 10 10:26:21 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Oct 2014 14:26:21 +0400 Subject: [9] Review Request: 8059943 [macosx] Aqua LaF should use BI.TYPE_INT_ARGB_PRE for a better performance In-Reply-To: <5437ADD1.5020305@oracle.com> References: <543798B0.3090203@oracle.com> <5437ADD1.5020305@oracle.com> Message-ID: <5437B44D.4080804@oracle.com> On 10.10.2014 13:58, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Is it possible to write an automated test for the fix? No, since these images are used internally. > > Thanks, > Alexandr. > > On 10/10/2014 12:28 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the small fix for jdk 9. >> Only TYPE_INT_ARGB_PRE is natively supported on osx in opengl >> pipeline(see OGLBlitLoops.java). Other types with alpha use >> OGLGeneralBlit which convert an image to argb_pre on the fly, this >> hurts a performance. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059943 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8059943/webrev.00 >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Fri Oct 10 11:35:47 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 10 Oct 2014 15:35:47 +0400 Subject: [9] Review Request: 8059943 [macosx] Aqua LaF should use BI.TYPE_INT_ARGB_PRE for a better performance In-Reply-To: <5437B44D.4080804@oracle.com> References: <543798B0.3090203@oracle.com> <5437ADD1.5020305@oracle.com> <5437B44D.4080804@oracle.com> Message-ID: <5437C493.5040508@oracle.com> Hello Sergey, The fix looks good to me. -- Thanks, Alexander. On 10/10/2014 02:26 PM, Sergey Bylokhov wrote: > On 10.10.2014 13:58, Alexander Scherbatiy wrote: >> >> The fix looks good to me. >> >> Is it possible to write an automated test for the fix? > No, since these images are used internally. >> >> Thanks, >> Alexandr. >> >> On 10/10/2014 12:28 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the small fix for jdk 9. >>> Only TYPE_INT_ARGB_PRE is natively supported on osx in opengl >>> pipeline(see OGLBlitLoops.java). Other types with alpha use >>> OGLGeneralBlit which convert an image to argb_pre on the fly, this >>> hurts a performance. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059943 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8059943/webrev.00 >>> >> > > From yuri.nesterenko at oracle.com Wed Oct 15 07:36:30 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 15 Oct 2014 11:36:30 +0400 Subject: [9] Review Request: JDK-8058805 Fix type in client-related package for tray.policy file missing in java/awt/TrayIcon/SecurityCheck/NoPermissionTest In-Reply-To: <542AB418.3070107@oracle.com> References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com> Message-ID: <543E23FE.1030002@oracle.com> Hi Pooja, perhaps it would be better to have _something_ in this policy file, for instance a comment. Thanks, -yan On 09/30/2014 05:46 PM, pooja chopra wrote: > Hello All, > Gentle reminder . Please review below fix . > > Regards, > Pooja > On 9/19/2014 5:04 PM, pooja chopra wrote: >> |Hello, | >> || >> |Please review a fix ||for| |the issue: | >> || >> |8058805| |[TEST_BUG] >> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| >> fails with Cant find Policy file error.||| >> || >> |Test bug fix. >> | >> || >> |https://bugs.openjdk.java.net/browse/JDK-8058805||| >> || >> | >> The webrev is: |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ | >> >> ||| >> || >> |Thanks | >> |Pooja| > From pooja.chopra at oracle.com Wed Oct 15 11:47:44 2014 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 15 Oct 2014 17:17:44 +0530 Subject: [9] Review Request: JDK-8058805 Fix type in client-related package for tray.policy file missing in java/awt/TrayIcon/SecurityCheck/NoPermissionTest In-Reply-To: <543E23FE.1030002@oracle.com> References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com> <543E23FE.1030002@oracle.com> Message-ID: <543E5EE0.6060408@oracle.com> Hi Yuri , I have added an empty grant block as this test requires No Permission :- //No Permission Test grant{ }; webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/ JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805 Please review further . Regards, Pooja On 10/15/2014 1:06 PM, Yuri Nesterenko wrote: > Hi Pooja, > > perhaps it would be better to have _something_ > in this policy file, for instance a comment. > > Thanks, > -yan > > On 09/30/2014 05:46 PM, pooja chopra wrote: >> Hello All, >> Gentle reminder . Please review below fix . >> >> Regards, >> Pooja >> On 9/19/2014 5:04 PM, pooja chopra wrote: >>> |Hello, | >>> || >>> |Please review a fix ||for| |the issue: | >>> || >>> |8058805| |[TEST_BUG] >>> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| >>> >>> fails with Cant find Policy file error.||| >>> || >>> |Test bug fix. >>> | >>> || >>> |https://bugs.openjdk.java.net/browse/JDK-8058805||| >>> || >>> | >>> The webrev is: >>> |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ | >>> >>> ||| >>> || >>> |Thanks | >>> |Pooja| >> > From yuri.nesterenko at oracle.com Wed Oct 15 12:39:17 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 15 Oct 2014 16:39:17 +0400 Subject: [9] Review Request: JDK-8058805 Fix type in client-related package for tray.policy file missing in java/awt/TrayIcon/SecurityCheck/NoPermissionTest In-Reply-To: <543E5EE0.6060408@oracle.com> References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com> <543E23FE.1030002@oracle.com> <543E5EE0.6060408@oracle.com> Message-ID: <543E6AF5.2000602@oracle.com> Hi Pooja, OK with me. -yan On 10/15/2014 03:47 PM, pooja chopra wrote: > Hi Yuri , > > I have added an empty grant block as this test requires No Permission :- > > //No Permission Test > grant{ > }; > > webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/ > JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805 > > Please review further . > Regards, > Pooja > On 10/15/2014 1:06 PM, Yuri Nesterenko wrote: >> Hi Pooja, >> >> perhaps it would be better to have _something_ >> in this policy file, for instance a comment. >> >> Thanks, >> -yan >> >> On 09/30/2014 05:46 PM, pooja chopra wrote: >>> Hello All, >>> Gentle reminder . Please review below fix . >>> >>> Regards, >>> Pooja >>> On 9/19/2014 5:04 PM, pooja chopra wrote: >>>> |Hello, | >>>> || >>>> |Please review a fix ||for| |the issue: | >>>> || >>>> |8058805| |[TEST_BUG] >>>> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| >>>> >>>> fails with Cant find Policy file error.||| >>>> || >>>> |Test bug fix. >>>> | >>>> || >>>> |https://bugs.openjdk.java.net/browse/JDK-8058805||| >>>> || >>>> | >>>> The webrev is: >>>> |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ | >>>> >>>> ||| >>>> || >>>> |Thanks | >>>> |Pooja| >>> >> > From alexandr.scherbatiy at oracle.com Wed Oct 15 14:09:56 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 15 Oct 2014 18:09:56 +0400 Subject: [9] Review request for 8059995 Broken link in Package javax.swing.border Message-ID: <543E8034.9020204@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8059995 webrev: http://cr.openjdk.java.net/~alexsch/8059995/webrev.00 Broken javadoc links are corrected. Thanks, Alexandr. From alexander.zvegintsev at oracle.com Wed Oct 15 15:15:42 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 15 Oct 2014 19:15:42 +0400 Subject: [9] Review request for 8059995 Broken link in Package javax.swing.border In-Reply-To: <543E8034.9020204@oracle.com> References: <543E8034.9020204@oracle.com> Message-ID: <543E8F9E.4060106@oracle.com> Hello Alexandr, the fix looks good to me. -- Thanks, Alexander. On 10/15/2014 06:09 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8059995 > webrev: http://cr.openjdk.java.net/~alexsch/8059995/webrev.00 > > Broken javadoc links are corrected. > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Thu Oct 16 13:16:18 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Oct 2014 17:16:18 +0400 Subject: [9] Review request for 8059995 Broken link in Package javax.swing.border In-Reply-To: <543E8034.9020204@oracle.com> References: <543E8034.9020204@oracle.com> Message-ID: <543FC522.4060306@oracle.com> Hi, Alexander. The fix looks good. On 15.10.2014 18:09, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8059995 > webrev: http://cr.openjdk.java.net/~alexsch/8059995/webrev.00 > > Broken javadoc links are corrected. > > Thanks, > Alexandr. > -- Best regards, Sergey. From pooja.chopra at oracle.com Thu Oct 16 16:21:12 2014 From: pooja.chopra at oracle.com (pooja chopra) Date: Thu, 16 Oct 2014 21:51:12 +0530 Subject: [9] Review Request: JDK-8058805 Fix type in client-related package for tray.policy file missing in java/awt/TrayIcon/SecurityCheck/NoPermissionTest In-Reply-To: <543E6AF5.2000602@oracle.com> References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com> <543E23FE.1030002@oracle.com> <543E5EE0.6060408@oracle.com> <543E6AF5.2000602@oracle.com> Message-ID: <543FF078.1020205@oracle.com> Hi Yuri , Thanks. Regards, Pooja On 10/15/2014 6:09 PM, Yuri Nesterenko wrote: > Hi Pooja, > > OK with me. > > -yan > > On 10/15/2014 03:47 PM, pooja chopra wrote: >> Hi Yuri , >> >> I have added an empty grant block as this test requires No >> Permission :- >> >> //No Permission Test >> grant{ >> }; >> >> webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/ >> JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805 >> >> Please review further . >> Regards, >> Pooja >> On 10/15/2014 1:06 PM, Yuri Nesterenko wrote: >>> Hi Pooja, >>> >>> perhaps it would be better to have _something_ >>> in this policy file, for instance a comment. >>> >>> Thanks, >>> -yan >>> >>> On 09/30/2014 05:46 PM, pooja chopra wrote: >>>> Hello All, >>>> Gentle reminder . Please review below fix . >>>> >>>> Regards, >>>> Pooja >>>> On 9/19/2014 5:04 PM, pooja chopra wrote: >>>>> |Hello, | >>>>> || >>>>> |Please review a fix ||for| |the issue: | >>>>> || >>>>> |8058805| |[TEST_BUG] >>>>> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| >>>>> >>>>> >>>>> fails with Cant find Policy file error.||| >>>>> || >>>>> |Test bug fix. >>>>> | >>>>> || >>>>> |https://bugs.openjdk.java.net/browse/JDK-8058805||| >>>>> || >>>>> | >>>>> The webrev is: >>>>> |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ | >>>>> >>>>> ||| >>>>> || >>>>> |Thanks | >>>>> |Pooja| >>>> >>> >> > From Sergey.Bylokhov at oracle.com Wed Oct 22 13:43:23 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Oct 2014 17:43:23 +0400 Subject: [9] Review Request: 7154054 [macosx] Can't distinguish the focus move to next cell Message-ID: <5447B47B.3020001@oracle.com> Hello. Please review the fix for jdk 9. - Tests were moved to the open repo. - MetalLookAndFeel now explicitly set in these tests + InvokeLater was added. Bug: https://bugs.openjdk.java.net/browse/JDK-7154054 Webrev can be found at: http://cr.openjdk.java.net/~serb/7154054/webrev.01 -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Oct 22 14:29:46 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 22 Oct 2014 18:29:46 +0400 Subject: [9] Review Request: 7154054 [macosx] Can't distinguish the focus move to next cell In-Reply-To: <5447B47B.3020001@oracle.com> References: <5447B47B.3020001@oracle.com> Message-ID: <5447BF5A.3080509@oracle.com> The fix looks good to me. Thanks, Alexandr. On 10/22/2014 5:43 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > - Tests were moved to the open repo. > - MetalLookAndFeel now explicitly set in these tests + InvokeLater > was added. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7154054 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7154054/webrev.01 > From alexander.zvegintsev at oracle.com Wed Oct 22 14:32:54 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Oct 2014 18:32:54 +0400 Subject: [9] Review Request: 7154054 [macosx] Can't distinguish the focus move to next cell In-Reply-To: <5447B47B.3020001@oracle.com> References: <5447B47B.3020001@oracle.com> Message-ID: <5447C016.40500@oracle.com> Hi Sergey, the fix looks good to me. Thanks, Alexander. On 10/22/2014 05:43 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > - Tests were moved to the open repo. > - MetalLookAndFeel now explicitly set in these tests + InvokeLater > was added. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7154054 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7154054/webrev.01 > From alexandr.scherbatiy at oracle.com Fri Oct 24 11:44:27 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Oct 2014 15:44:27 +0400 Subject: [9] Review request for 8061592 wrong javadoc parameters for firePropertyChange() Message-ID: <544A3B9B.1080803@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8061592 webrev: http://cr.openjdk.java.net/~alexsch/8061592/webrev.00 Typo in the newValue parameter description is fixed. Thanks, Alexandr. From alexander.zvegintsev at oracle.com Fri Oct 24 11:49:06 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 24 Oct 2014 15:49:06 +0400 Subject: [9] Review request for 8061592 wrong javadoc parameters for firePropertyChange() In-Reply-To: <544A3B9B.1080803@oracle.com> References: <544A3B9B.1080803@oracle.com> Message-ID: <544A3CB2.8050604@oracle.com> Hello Alexandr, the fix looks fine to me. Thanks, Alexander. On 10/24/2014 03:44 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8061592 > webrev: http://cr.openjdk.java.net/~alexsch/8061592/webrev.00 > > Typo in the newValue parameter description is fixed. > > Thanks, > Alexandr. > From helpcrypto at gmail.com Mon Oct 27 13:06:18 2014 From: helpcrypto at gmail.com (helpcrypto helpcrypto) Date: Mon, 27 Oct 2014 14:06:18 +0100 Subject: Autosize dialog pack() seems to be buggy on Linux Message-ID: Hi. I'm usually at icedtea web maillist, but this bug seems to be 100% swing-related. I'm trying to display a dialog, centered on screen, which size is fitted to changing contents. AFAIK, this should be done using pack(). Running the "attached testcase", I have noticed two things: - After each pack, as the BorderLayout seem to be center-resized, the window moves down after each click (but pack always seem to work). IMHO this is not a friendly behaviour, but can be solved adding a setLocationRelativeTo after pack - If I add a setLocationRelativeTo (as shown below) pack fails from time to time and incorrectly sizes the dialog. Can you guys help me? Registered this bug a few weeks ago: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1798 package testcase; import java.awt.BorderLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.lang.reflect.InvocationTargetException; import java.util.logging.Level; import java.util.logging.Logger; import javax.swing.*; import javax.swing.border.EmptyBorder; public class Testcase extends JDialog { private JPanel panel; private JLabel label; private JButton foo; private JButton bar; public Testcase() { setTitle("Test"); setModal(true); setResizable(false); setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); foo = new JButton(); foo.setText("foo"); foo.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { foo(); } }); foo.setVisible(true); bar = new JButton(); bar.setText("bar"); bar.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { bar(); } }); bar.setVisible(true); label = new JLabel(); label.setBorder(new EmptyBorder(10, 10, 10, 10)); label.setText("a"); panel = new JPanel(); panel.setLayout(new BorderLayout()); panel.setVisible(true); panel.setBorder(new EmptyBorder(10, 10, 10, 10)); panel.add(foo, BorderLayout.NORTH); panel.add(label, BorderLayout.CENTER); panel.add(bar, BorderLayout.SOUTH); getContentPane().add(panel); pack(); //validate(); //repaint(); setLocationRelativeTo(null); } public void foo(){ label.setText(""+ "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo" + "
"+ "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo" + "
"+ "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo" + "
"+ "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo" + "
"+ "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo" + ""); pack(); //validate(); //repaint(); setLocationRelativeTo(null); } public void bar(){ label.setText("bar"); pack(); //validate(); //repaint(); setLocationRelativeTo(null); } public static void main(String[] args) { try { SwingUtilities.invokeAndWait(new Runnable() { @Override public void run() { JDialog test= new Testcase(); test.setVisible(true); } }); } catch (InterruptedException | InvocationTargetException ex) { Logger.getLogger(Testcase.class.getName()).log(Level.SEVERE, null, ex); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.porvatov at oracle.com Tue Oct 28 09:57:40 2014 From: pavel.porvatov at oracle.com (pavel porvatov) Date: Tue, 28 Oct 2014 13:57:40 +0400 Subject: Result: New SWING Group Lead: Alexander Scherbatiy Message-ID: <544F6894.2080108@oracle.com> Voting for SWING Group Lead Alexander Scherbatiy [1] is now closed. Yes: 3 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority, this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Pavel Porvatov [1] http://mail.openjdk.java.net/pipermail/swing-dev/2014-September/003878.html From alexandr.scherbatiy at oracle.com Wed Oct 29 21:33:10 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 30 Oct 2014 01:33:10 +0400 Subject: Autosize dialog pack() seems to be buggy on Linux In-Reply-To: References: Message-ID: <54515D16.20703@oracle.com> Hi, Could you create an issue on it: http://bugreport.java.com/bugreport Thanks, Alexandr. On 10/27/2014 5:06 PM, helpcrypto helpcrypto wrote: > Hi. > > > I'm usually at icedtea web maillist, but this bug seems to be 100% > swing-related. > > I'm trying to display a dialog, centered on screen, which size is > fitted to changing contents. > AFAIK, this should be done using pack(). > > > Running the "attached testcase", I have noticed two things: > > - After each pack, as the BorderLayoutseem to be center-resized, the > window moves down after each click (but pack always seem to work). > IMHO this is not a friendly behaviour, but can be solved adding a > setLocationRelativeToafter pack > - If I add a setLocationRelativeTo(as shown below) pack fails from > time to time and incorrectly sizes the dialog. > > Can you guys help me? > Registered this bug a few weeks ago: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1798 > > > package testcase; > import java.awt.BorderLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > import java.lang.reflect.InvocationTargetException; > import java.util.logging.Level; > import java.util.logging.Logger; > import javax.swing.*; > import javax.swing.border.EmptyBorder; > public class Testcase extends JDialog { > private JPanel panel; > private JLabel label; > private JButton foo; > private JButton bar; > public Testcase() { > setTitle("Test"); > setModal(true); > setResizable(false); > setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); > foo = new JButton(); > foo.setText("foo"); > foo.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > foo(); > } > }); > foo.setVisible(true); > bar = new JButton(); > bar.setText("bar"); > bar.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > bar(); > } > }); > bar.setVisible(true); > label = new JLabel(); > label.setBorder(new EmptyBorder(10, 10, 10, 10)); > label.setText("a"); > panel = new JPanel(); > panel.setLayout(new BorderLayout()); > panel.setVisible(true); > panel.setBorder(new EmptyBorder(10, 10, 10, 10)); > panel.add(foo, BorderLayout.NORTH); > panel.add(label, BorderLayout.CENTER); > panel.add(bar, BorderLayout.SOUTH); > getContentPane().add(panel); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public void foo(){ > label.setText(""+ > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > ""); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public void bar(){ > label.setText("bar"); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public static void main(String[] args) { > try { > SwingUtilities.invokeAndWait(new Runnable() { > @Override > public void run() { > JDialog test= new Testcase(); > test.setVisible(true); > } > }); > } catch (InterruptedException | InvocationTargetException ex) { > > Logger.getLogger(Testcase.class.getName()).log(Level.SEVERE, null, > ex); > } > } > } > From alexandr.scherbatiy at oracle.com Wed Oct 29 21:43:51 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 30 Oct 2014 01:43:51 +0400 Subject: [9] Review request for 8057893 JComboBox actionListener never receives "comboBoxEdited" from getActionCommand Message-ID: <54515F97.3030302@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8057893 webrev: http://cr.openjdk.java.net/~alexsch/8057893/webrev.00 This is a regression from the fix 8019180. The event source should be compared with the ComboBoxEditor editor component. Thanks, Alexandr. From helpcrypto at gmail.com Wed Oct 29 11:22:26 2014 From: helpcrypto at gmail.com (helpcrypto helpcrypto) Date: Wed, 29 Oct 2014 12:22:26 +0100 Subject: Autosize dialog pack() seems to be buggy on Linux In-Reply-To: <54515D16.20703@oracle.com> References: <54515D16.20703@oracle.com> Message-ID: AFAICT it only happens on icedtea Do you want me to report it at oracle anyway? Regards. On Wed, Oct 29, 2014 at 10:33 PM, Alexander Scherbatiy < alexandr.scherbatiy at oracle.com> wrote: > > Hi, > > Could you create an issue on it: http://bugreport.java.com/bugreport > > Thanks, > Alexandr. > > On 10/27/2014 5:06 PM, helpcrypto helpcrypto wrote: > >> Hi. >> >> >> I'm usually at icedtea web maillist, but this bug seems to be 100% >> swing-related. >> >> I'm trying to display a dialog, centered on screen, which size is fitted >> to changing contents. >> AFAIK, this should be done using pack(). >> >> >> Running the "attached testcase", I have noticed two things: >> >> - After each pack, as the BorderLayoutseem to be center-resized, the >> window moves down after each click (but pack always seem to work). IMHO >> this is not a friendly behaviour, but can be solved adding a >> setLocationRelativeToafter pack >> - If I add a setLocationRelativeTo(as shown below) pack fails from time >> to time and incorrectly sizes the dialog. >> >> Can you guys help me? >> Registered this bug a few weeks ago: http://icedtea.classpath.org/ >> bugzilla/show_bug.cgi?id=1798 >> >> >> package testcase; >> import java.awt.BorderLayout; >> import java.awt.event.ActionEvent; >> import java.awt.event.ActionListener; >> import java.lang.reflect.InvocationTargetException; >> import java.util.logging.Level; >> import java.util.logging.Logger; >> import javax.swing.*; >> import javax.swing.border.EmptyBorder; >> public class Testcase extends JDialog { >> private JPanel panel; >> private JLabel label; >> private JButton foo; >> private JButton bar; >> public Testcase() { >> setTitle("Test"); >> setModal(true); >> setResizable(false); >> setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); >> foo = new JButton(); >> foo.setText("foo"); >> foo.addActionListener(new ActionListener() { >> @Override >> public void actionPerformed(ActionEvent e) { >> foo(); >> } >> }); >> foo.setVisible(true); >> bar = new JButton(); >> bar.setText("bar"); >> bar.addActionListener(new ActionListener() { >> @Override >> public void actionPerformed(ActionEvent e) { >> bar(); >> } >> }); >> bar.setVisible(true); >> label = new JLabel(); >> label.setBorder(new EmptyBorder(10, 10, 10, 10)); >> label.setText("a"); >> panel = new JPanel(); >> panel.setLayout(new BorderLayout()); >> panel.setVisible(true); >> panel.setBorder(new EmptyBorder(10, 10, 10, 10)); >> panel.add(foo, BorderLayout.NORTH); >> panel.add(label, BorderLayout.CENTER); >> panel.add(bar, BorderLayout.SOUTH); >> getContentPane().add(panel); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public void foo(){ >> label.setText(""+ >> "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoo"+ >> ""); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public void bar(){ >> label.setText("bar"); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public static void main(String[] args) { >> try { >> SwingUtilities.invokeAndWait(new Runnable() { >> @Override >> public void run() { >> JDialog test= new Testcase(); >> test.setVisible(true); >> } >> }); >> } catch (InterruptedException | InvocationTargetException ex) { >> Logger.getLogger(Testcase.class.getName()).log(Level.SEVERE, >> null, >> ex); >> } >> } >> } >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Oct 30 00:15:59 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 30 Oct 2014 04:15:59 +0400 Subject: Autosize dialog pack() seems to be buggy on Linux In-Reply-To: References: <54515D16.20703@oracle.com> Message-ID: <5451833F.7010301@oracle.com> On 10/29/2014 3:22 PM, helpcrypto helpcrypto wrote: > AFAICT it only happens on icedtea > > Do you want me to report it at oracle anyway? Yes. You can start the summary with the [IcedTea] prefix. Thanks, Alexandr. > > Regards. > > On Wed, Oct 29, 2014 at 10:33 PM, Alexander Scherbatiy > > wrote: > > > Hi, > > Could you create an issue on it: http://bugreport.java.com/bugreport > > Thanks, > Alexandr. > > On 10/27/2014 5:06 PM, helpcrypto helpcrypto wrote: > > Hi. > > > I'm usually at icedtea web maillist, but this bug seems to be > 100% swing-related. > > I'm trying to display a dialog, centered on screen, which size > is fitted to changing contents. > AFAIK, this should be done using pack(). > > > Running the "attached testcase", I have noticed two things: > > - After each pack, as the BorderLayoutseem to be > center-resized, the window moves down after each click (but > pack always seem to work). IMHO this is not a friendly > behaviour, but can be solved adding a > setLocationRelativeToafter pack > - If I add a setLocationRelativeTo(as shown below) pack fails > from time to time and incorrectly sizes the dialog. > > Can you guys help me? > Registered this bug a few weeks ago: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1798 > > > package testcase; > import java.awt.BorderLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > import java.lang.reflect.InvocationTargetException; > import java.util.logging.Level; > import java.util.logging.Logger; > import javax.swing.*; > import javax.swing.border.EmptyBorder; > public class Testcase extends JDialog { > private JPanel panel; > private JLabel label; > private JButton foo; > private JButton bar; > public Testcase() { > setTitle("Test"); > setModal(true); > setResizable(false); > setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); > foo = new JButton(); > foo.setText("foo"); > foo.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > foo(); > } > }); > foo.setVisible(true); > bar = new JButton(); > bar.setText("bar"); > bar.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > bar(); > } > }); > bar.setVisible(true); > label = new JLabel(); > label.setBorder(new EmptyBorder(10, 10, 10, 10)); > label.setText("a"); > panel = new JPanel(); > panel.setLayout(new BorderLayout()); > panel.setVisible(true); > panel.setBorder(new EmptyBorder(10, 10, 10, 10)); > panel.add(foo, BorderLayout.NORTH); > panel.add(label, BorderLayout.CENTER); > panel.add(bar, BorderLayout.SOUTH); > getContentPane().add(panel); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public void foo(){ > label.setText(""+ > > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > "
"+ > > "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ > ""); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public void bar(){ > label.setText("bar"); > pack(); > //validate(); > //repaint(); > setLocationRelativeTo(null); > } > public static void main(String[] args) { > try { > SwingUtilities.invokeAndWait(new Runnable() { > @Override > public void run() { > JDialog test= new Testcase(); > test.setVisible(true); > } > }); > } catch (InterruptedException | InvocationTargetException > ex) { > > Logger.getLogger(Testcase.class.getName()).log(Level.SEVERE, > null, > ex); > } > } > } > > > From helpcrypto at gmail.com Wed Oct 29 13:46:04 2014 From: helpcrypto at gmail.com (helpcrypto helpcrypto) Date: Wed, 29 Oct 2014 14:46:04 +0100 Subject: Autosize dialog pack() seems to be buggy on Linux In-Reply-To: <5451833F.7010301@oracle.com> References: <54515D16.20703@oracle.com> <5451833F.7010301@oracle.com> Message-ID: Review ID: JI-9016178) - [IcedTea]Autosize dialog pack() seems to be buggy on Linux Done ;) On Thu, Oct 30, 2014 at 1:15 AM, Alexander Scherbatiy < alexandr.scherbatiy at oracle.com> wrote: > On 10/29/2014 3:22 PM, helpcrypto helpcrypto wrote: > >> AFAICT it only happens on icedtea >> >> Do you want me to report it at oracle anyway? >> > > Yes. You can start the summary with the [IcedTea] prefix. > > Thanks, > Alexandr. > >> >> Regards. >> >> >> On Wed, Oct 29, 2014 at 10:33 PM, Alexander Scherbatiy < >> alexandr.scherbatiy at oracle.com > >> wrote: >> >> >> Hi, >> >> Could you create an issue on it: http://bugreport.java.com/ >> bugreport >> >> Thanks, >> Alexandr. >> >> On 10/27/2014 5:06 PM, helpcrypto helpcrypto wrote: >> >> Hi. >> >> >> I'm usually at icedtea web maillist, but this bug seems to be >> 100% swing-related. >> >> I'm trying to display a dialog, centered on screen, which size >> is fitted to changing contents. >> AFAIK, this should be done using pack(). >> >> >> Running the "attached testcase", I have noticed two things: >> >> - After each pack, as the BorderLayoutseem to be >> center-resized, the window moves down after each click (but >> pack always seem to work). IMHO this is not a friendly >> behaviour, but can be solved adding a >> setLocationRelativeToafter pack >> - If I add a setLocationRelativeTo(as shown below) pack fails >> from time to time and incorrectly sizes the dialog. >> >> Can you guys help me? >> Registered this bug a few weeks ago: >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1798 >> >> >> package testcase; >> import java.awt.BorderLayout; >> import java.awt.event.ActionEvent; >> import java.awt.event.ActionListener; >> import java.lang.reflect.InvocationTargetException; >> import java.util.logging.Level; >> import java.util.logging.Logger; >> import javax.swing.*; >> import javax.swing.border.EmptyBorder; >> public class Testcase extends JDialog { >> private JPanel panel; >> private JLabel label; >> private JButton foo; >> private JButton bar; >> public Testcase() { >> setTitle("Test"); >> setModal(true); >> setResizable(false); >> setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); >> foo = new JButton(); >> foo.setText("foo"); >> foo.addActionListener(new ActionListener() { >> @Override >> public void actionPerformed(ActionEvent e) { >> foo(); >> } >> }); >> foo.setVisible(true); >> bar = new JButton(); >> bar.setText("bar"); >> bar.addActionListener(new ActionListener() { >> @Override >> public void actionPerformed(ActionEvent e) { >> bar(); >> } >> }); >> bar.setVisible(true); >> label = new JLabel(); >> label.setBorder(new EmptyBorder(10, 10, 10, 10)); >> label.setText("a"); >> panel = new JPanel(); >> panel.setLayout(new BorderLayout()); >> panel.setVisible(true); >> panel.setBorder(new EmptyBorder(10, 10, 10, 10)); >> panel.add(foo, BorderLayout.NORTH); >> panel.add(label, BorderLayout.CENTER); >> panel.add(bar, BorderLayout.SOUTH); >> getContentPane().add(panel); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public void foo(){ >> label.setText(""+ >> "foofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ >> "
"+ >> "foofoofoofoofoofoofoofoofoofoo >> foofoofoofoofoofoofoofoofoofoofoofoofoofoofoo"+ >> ""); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public void bar(){ >> label.setText("bar"); >> pack(); >> //validate(); >> //repaint(); >> setLocationRelativeTo(null); >> } >> public static void main(String[] args) { >> try { >> SwingUtilities.invokeAndWait(new Runnable() { >> @Override >> public void run() { >> JDialog test= new Testcase(); >> test.setVisible(true); >> } >> }); >> } catch (InterruptedException | InvocationTargetException >> ex) { >> Logger.getLogger(Testcase. >> class.getName()).log(Level.SEVERE, >> null, >> ex); >> } >> } >> } >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Oct 29 15:26:15 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Oct 2014 18:26:15 +0300 Subject: [9] Review request for 8057893 JComboBox actionListener never receives "comboBoxEdited" from getActionCommand In-Reply-To: <54515F97.3030302@oracle.com> References: <54515F97.3030302@oracle.com> Message-ID: <54510717.2040201@oracle.com> Hi, Alexander. The fix looks good. On 30.10.2014 0:43, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8057893 > webrev: http://cr.openjdk.java.net/~alexsch/8057893/webrev.00 > > This is a regression from the fix 8019180. > The event source should be compared with the ComboBoxEditor editor > component. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu Oct 30 12:00:02 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 30 Oct 2014 15:00:02 +0300 Subject: [9] Review request for 8057893 JComboBox actionListener never receives "comboBoxEdited" from getActionCommand In-Reply-To: <54510717.2040201@oracle.com> References: <54515F97.3030302@oracle.com> <54510717.2040201@oracle.com> Message-ID: <54522842.4080203@oracle.com> Hi Alexandr, the fix looks good to me too. Thanks, Alexander. On 29/10/14 18:26, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 30.10.2014 0:43, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8057893 >> webrev: http://cr.openjdk.java.net/~alexsch/8057893/webrev.00 >> >> This is a regression from the fix 8019180. >> The event source should be compared with the ComboBoxEditor editor >> component. >> >> Thanks, >> Alexandr. >> > > From Sergey.Bylokhov at oracle.com Fri Oct 31 20:08:27 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 Oct 2014 23:08:27 +0300 Subject: [9] Review Request: 7195187 [TEST_BUG] [macosx] javax/swing/SwingUtilities/7088744/bug7088744.java failed Message-ID: <5453EC3B.5000107@oracle.com> Hello. Please review the small fix for jdk 9: - frame was moved to the center of the screen, and now it is disposed at the end - center of the label is used for click - realSync() was replaced by the waitForIdle() Bug: https://bugs.openjdk.java.net/browse/JDK-7195187 Webrev can be found at: http://cr.openjdk.java.net/~serb/7195187/webrev.00 -- Best regards, Sergey.