PropertyChangeListener installed on the current
the KeyboardFocusManager's context, even though the
focus owner, focused Window, active Window, and current focus cycle
root comprise the global focus state shared by all contexts.
-We believe this is less intrusive than requiring client code to pass
-a security check before installing a PropertyChangeListener.
Component supports the following focus-related properties:
@@ -1195,26 +1193,6 @@ KeyEventPostProcessors, FocusTraversalPolicies,
VetoableChangeListeners, and other concepts discussed in this document
before resorting to a full replacement of the KeyboardFocusManager.
-First note that, because unhindered access to Components in other
-contexts represents a security hole, the SecurityManager must grant a
-new permission, "replaceKeyboardFocusManager", before client code is
-permitted to replace the KeyboardFocusManager with an arbitrary
-subclass instance. Because of the security check, replacing the
-KeyboardFocusManager is not an option for applications that will be
-deployed in environments with a SecurityManager, such as applets in a
-browser.
-
-Once installed, a KeyboardFocusManager instance has
-access to the global focus state via a set of protected functions.
-The KeyboardFocusManager can only call these functions
-if it is installed in the calling thread's context. This ensures
-that malicious code cannot circumvent the security check in
-KeyboardFocusManager.setCurrentFocusManager.
-A KeyboardFocusManager should always work with
-the global focus state instead of the context focus state.
-Failure to do this will lead to incorrect behavior of the
-KeyboardFocusManager.
-
The primary responsibility of a KeyboardFocusManager
is the dispatch of the following events: