Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application.

Artem Ananiev artem.ananiev at oracle.com
Wed Feb 29 09:30:49 PST 2012


Approved!

Thanks,

Artem

On 2/29/2012 4:48 AM, Anton V. Tarasov wrote:
> Ok, I did it:
>
> http://cr.openjdk.java.net/~ant/7125044/webrev.3/
>
> (Now I know there may be several @run targets = )
>
> Thanks,
> Anton.
>
> On 28.02.2012 21:24, Artem Ananiev wrote:
>> Hi, Anton,
>>
>> the webrev looks fine. As a possible optimization, you can try to
>> combine the two tests into a single one with several @run tags, but
>> I'm leaving it up to you :)
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/28/2012 5:15 AM, Anton V. Tarasov wrote:
>>> Hi All,
>>>
>>> Sorry for providing the wrong links (and thanks for the correction).
>>>
>>> On 2/28/12 2:58 AM, Artem Ananiev wrote:
>>>>
>>>> Here is the text from 7125044's Suggested Fix:
>>>>
>>>> ---- quote begins ----
>>>>
>>>> In the fix it's assumed that swing toplevel initialization process
>>>> initiates JRootPane creation which in its turn updates UI where swing
>>>> layout focus policy is eventually set. For exmple, for JFrame the
>>>> stack looks as follows:
>>>>
>>>> at
>>>> javax.swing.UIManager.maybeInitializeFocusPolicy(UIManager.java:1440)
>>>> at javax.swing.UIManager.getUI(UIManager.java:1004)
>>>> at javax.swing.JRootPane.updateUI(JRootPane.java:483)
>>>> at javax.swing.JRootPane.<init>(JRootPane.java:370)
>>>> at javax.swing.JFrame.createRootPane(JFrame.java:277)
>>>> at javax.swing.JFrame.frameInit(JFrame.java:258)
>>>> at javax.swing.JFrame.<init>(JFrame.java:181)
>>>>
>>>> Also the fix eliminates the code in SunToolkit.checkAndSetPolicy(..)
>>>> that determined focus traversal policy for XAWT container. Now the
>>>> policy is taken from KeyboardFocusManager strictly following javadoc.
>>>>
>>>> ---- quote ends ----
>>>>
>>>> In general, the fix is a little bit hacky (see Anton's assumption
>>>> about Swing initialization above), but it's definitely simpler and
>>>> clearer than the current code. So I'm fine with it.
>>>
>>> The fix is based on the fact that a swing toplevel always creates
>>> JRootPane and that any JComponent requests for UIManager and that this
>>> is an integral part of swing architecture.
>>> I could directly initialize focus policy from every swing toplevel, but
>>> I thought using the code flow listed above was better.
>>>
>>>>
>>>> Anton,
>>>>
>>>> did you consider creating a new test, or several regression tests with
>>>> this fix? For example, a test that checks that in a pure AWT
>>>> application the default policy is DFTP (even if it contains text
>>>> components and runs on X11).
>>>
>>> I relied on the four tonga tests mentioned in the CR. Though I agree
>>> some new tests are quite reasonable here. I made them (tested with X11
>>> as well):
>>>
>>> http://cr.openjdk.java.net/~ant/7125044/webrev.2/
>>>
>>> Thanks,
>>> Anton.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/27/2012 3:02 PM, Roger Lewis wrote:
>>>>> The bugs are available, but this view does not include the
>>>>> Suggested Fix
>>>>> field.
>>>>>
>>>>> On 2/27/12 2:23 PM, Mike Swingler wrote:
>>>>>> On Feb 27, 2012, at 9:05 AM, Anton V. Tarasov wrote:
>>>>>>
>>>>>>> Detailed description:
>>>>>>>
>>>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7125044#Evaluation
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125044
>>>>>>>
>>>>>>> Fix description:
>>>>>>>
>>>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7125044#SuggestedFix
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125044
>>>>>
>>>>> -Roger
>>>>>
>>>>>
>>>>>
>>>>>> Neither of these are visible outside of Oracle.
>>>>>>
>>>>>> Regards,
>>>>>> Mike Swingler
>>>>>> Apple Inc.
>>>>>>
>>>
>


More information about the macosx-port-dev mailing list