<Swing Dev> RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

[Pete Brunet]

On 6/30/16 11:51 AM, Alexander Scherbatiy wrote:
>
> The fix looks good to me.
>
> Please, run the regression and JCK tests to be sure that there are no
> possible regressions.
jtreg for my test case and JCK for JComboBox both ran OK.  Are there
other tests you'd like me to run. 

If so please let me know the invocations to use.  For the above tests I
did the following:

./build/windows-x86_64-normal-server-release/jdk/bin/java -jar
"c:/Users/Pete/JDK9/JCK/JCK-runtime-9/lib/jtjck.jar"
"api/javax_swing/JComboBox"

and

/cygdrive/c/Users/Pete/jtreg/bin/jtreg
-jdk:./build/windows-x86_64-normal-server-release/images/jdk
./jdk/test/javax/swing/plaf/basic/BasicComboPopup/8154069/

Thanks, Pete
>
> Thanks,
> Alexandr.
>
> On 30/06/16 18:49, Pete Brunet wrote:
>>
>> On 6/30/16 8:28 AM, Pete Brunet wrote:
>>> Please review the following:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069
>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/
>>>
>>> The scenario is resetting a second combo box via setSelectedIndex(-1)
>>> when a first combo box changes.  With the fix the selection is now
>>> cleared.
>>>
>>> jtreg for my test case and JCK for JComboBox both ran OK.
>>>
>>> 3 of 9 JPRT build jobs failed (Mac and both Windows).  There is nothing
>>> about the patch that should cause a build problem on those three
>>> platforms so I assume the failures are due to some other unrelated
>>> issue.  I'll check to see who might know what's going on with the JPRT
>>> builds.
>> I've been informed the JPRT build fix is known and in review.
>>> TiA, Pete
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160630/97e4c74d/attachment.html>