Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application. (original) (raw)
Anton V. Tarasov anton.tarasov at oracle.com
Tue Feb 28 05:15:03 PST 2012
- Previous message: Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application.
- Next message: Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.(JRootPane.java:370) at javax.swing.JFrame.createRootPane(JFrame.java:277) at javax.swing.JFrame.frameInit(JFrame.java:258) at javax.swing.JFrame.(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/viewbug.do?bugid=7125044 Fix description: http://monaco.us.oracle.com/detail.jsf?cr=7125044#SuggestedFix http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7125044 -Roger
Neither of these are visible outside of Oracle. Regards, Mike Swingler Apple Inc.
- Previous message: Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application.
- Next message: Review request for 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]