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

Artem Ananiev artem.ananiev at oracle.com
Tue Feb 28 09:24:51 PST 2012


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