JDK-4300028 : Wait cursor should not generate events any more
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-12-16
  • Updated: 2000-03-02
  • Resolved: 2000-03-02
Related Reports
Duplicate :  
Description

Name: skT88420			Date: 12/16/99


java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

Semantics of a wait cursor: Normally when the user sees a wait cursor, the
program is processing some previous input and does not wish to get any more
input until the point where the previous request is processed and the normal
cursor appears again.

Current implementation: In JDK the wait cursor just means that the shape of the
cursor changes, but that has no impact on the way events are generated and
processed.

Problem: The user may generate new events (especially in multithreaded Swing
programs), that possibly lead to big trouble.

Example: User clicks on item. That events starts a database search. Wait cursor
appears. User clicks (though wait cursor is shown) on other item. Another
database search is started, although the first one is still running. That may
easily corrupt your data structures.

I would like to have an EASY way of preventing this. One thread (AWT Thread
processes action) is not enough, because that makes your GUI hang (no redraw
while long database actions). So one second thread is needed that is triggered
by events: AWT thread may continue to redraw etc., second thread processes
e.g. database action.

Problem: AWT thread may still generate lots of key/mouse events, that the AWT
components itself react on. So it's not sufficient to design my second thread in
a First In-First Out style (one action at a time).

I really look for an EASY way to disable e.g. my complete panels in a way that
they don't see any input events any more. I tried setEnabled(false), but e.g. on
a JTree I still get selectionChanged events (that trigger my database
search...)

Security impact: Users might try to bring your application into an undefined
state (some components redraw from Vectors that are just being filled by a
second thread) in order to see information they are not allowed to see or crash
it at all (denial of service attack).
(Review ID: 99083) 
======================================================================

Comments
WORK AROUND Name: skT88420 Date: 12/16/99 I guess none acceptable. Using only one thread blocks the complete GUI (even redraw, looks inacceptable). Using two threads (second thread processing actions linearly, one after the other) already brings you in trouble, see above. ======================================================================
11-06-2004

EVALUATION I agree that Swing should support an easy way for disabling container hierarchies with a single setEnabled(false) call, however I disagree that this should be at all tied to setting of the wait cursor (programs may wish to use different cursors to denote a wait state). We are planning on adding the support for container disabling/enabling in merlin. This is a duplicate of #4177727. amy.fowler@Eng 2000-03-01
01-03-2000