|
Evaluation
|
Committing to merlin. Severe regression.
xxxxx@xxxxx 2001-07-11
Not reproducible on b69.
Reproducible on b73.
xxxxx@xxxxx 2001-08-02
======================================================================
commit to hopper and tiger
======================================================================
The bug is still reproducible with Hopper b02. However, it takes time to reproduce it,
also you need to mix keyboard and mouse item selection. After the problem has been
reproduced key events are still being reported in Java, but seems that they are not
being correcly dispatched to Motif. Also Choice doesn't have focus frame while it is
focused.
xxxxx@xxxxx
======================================================================
Two problems I see here with this particular test:
- focus owner is getting cleared every time we click on Window
(or its child) because of proxy activation-deactivation. This needs
to be investigated. However, this problem is more general and deep than
just 'choice focus problem', it affects other components as well.
- focus on widgets is requested when Window's shell is not active in terms
of how Motif treats active shells. Thus, focus requests are processed differently
in this case comparing to active shell. Again, it is because of proxy and it is
also very general problem.
In the case of Frame(test/java/awt/Focus/AltTabFocus for example) choice behaves well
in Hopper, I think it is because there is no Motif 1.2.
So, this bug requires more deep investigation, but we don't have a time for it
in Hopper, so I commit it to Mantis.
xxxxx@xxxxx 2002-03-11
======================================================================
Focus gets cleared because of FocusOut event coming due to raised popup shell -
choice's GrabShell. We should avoid generating Java events for this event. One
of the possible solutions is to use already existing skipNextNotifyWhileGrabbed
variable which is being set when grab shell arises.
Another problem discovered while investigating this bug: as from Mantis b02 the
problem with two keys on one press exists again(see 4495473). It is now because
all key events in Window come to peers twice - in
dispatchEventImpl(Component.java:3490) and
dispatchKeyEvent(DefaultKeyboardFocusManager:658). The error is in
Component.java - the code there doesn't take into account that it will be called
from inside DKFM dispatch event sequence and at the end of it normal
peer.handleEvent will be called. To prevent doble-dispatching we should consume
the event in Component.java as the code there assumes that no further processing
of the event occurs. Also, to simplify the code in dispatchEventImpl this code
should better be moved to join other parts of code dealing with key event
pre-dispatching - to preDispatchKeyEvent(DKFM:781).
One problem still exists - after I select some item from the choice's list using mouse
choice doesn't regain focus after closing of the menu.
xxxxx@xxxxx 2002-10-14
======================================================================
|
