292757 - Insertion of keystroke events (WM_CHAR) with system call PostMessage does not work when wParam is a control character.

Status: RESOLVED INCOMPLETE

(Core :: Widget: Win32, defect)

Description

[Eric Hughes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Use Case: automate Firefox as a drop source for unit testing of a drop target.

I have been trying to use Firefox as a drop source with a "file:" URL.  I can
spawn Firefox fine and the local file comes up.  I have been unable to get rid
of the window by inserting a ^W keystroke event into the message queue.  This
test need to be completely automated.  Manually closing the window (which works)
after the unit test finishes is an unacceptable, non-automated step.

Several methods of inserting keystroke events all fail to work.  Straight
WM_CHAR message doesn't.  I've also tried WM_KEYDOWN and WM_KEYUP with the
Control and W keys.  I've tried a few other combinations (unrealistic from a
real device but which might have tricked the software).  None have worked.

I pretty much know what the problem is from examining the source.  See
"Additional Information".

At this point I'm abandoning use of Firefox for (ick) Internet Explorer, because
I'm sure that it was written with automation support working.

I would recommend fixing this for purely internal reasons to be able to automate
conformance and regression testing of Firefox itself.

Reproducible: Always

Steps to Reproduce:
0. Have an Ada95 development system with GNAT and GPS on your machine.  OK, this
is unrealistic for most Mozilla developers.
1. Spawn Firefox with win32 call "CreateProcess"
2. Get a window handle with win32 call "FindWindow"
3. Insert a message in the the window's message queue with win32 call
"PostMessage".  Message parameters are Msg=WM_CHAR, wParam=23 (==ASCII ^W)

Actual Results:  
The inserted keystroke is ignored.

Expected Results:  
The tab that opened when Firefox spawned should have closed.

The bulk of the problem is in the file <a
href="http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp">/widget/src/windows/nsWindow.cpp</a>.
   For WM_CHAR messages, the culprit is <a
href="http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#3641">OnChar</a>,
which first uses the win32 call GetKeyState (through IS_VK_DOWN) to grab the
current, <b>actual</b> positions of the virtual shift-ctrl-alt keys.  It then
only sets the Unicode character value for a control code if the control key is
currently down.  If it's not down, it sets the Unicode value to 0 (line 3687).

The problem here is intermingling two data that are not guaranteed to be
compatible:  the <b>current</b> positions of the control key and an
<b>previous</b> (because enqueued) keystroke event. I'm sure this has also led
to practically-unreproducible misbehaviors from split-second timing.

There's essentially the same problem handling WM_KEYUP and WM_KEYDOWN messages.
 The first thing that the code to handle them does is to grab the current state
of the virtual shift-control-alt keys.

I cannot work around this defect because the state of the virtual keys is not
able to be set from outside the process.  I cannot insert events to change the
state of these keys, since it's essentially a query into the hardware driver for
the keyboard.

Apparently the whole reason to grab the current state of these virtual keys is
to workaround some of the weirdness in the way that Windows generates keystroke
events (such as with alt-space, mentioned in documentation).  Fine, but this
workaround should not interfere with ordinary event insertion.

The quick fix may be to set the Unicode character value to something other than
zero--maybe that doesn't cause problems elsewhere.  I can't tell.

The real fix is going to be to create a state machine object for unified
handling of all WM_*CHAR* and WM_*KEY* messages.  Already there's a spread-out
version of this when OnKeyDown (line 3503) uses PeekMessage to find and
GetMessage to remove WM_CHAR messages.  And there's a really ugly hack to fix a
Ctrl-BS problem with Japanese text entry from last year.  A state machine would
unify all this.  Rather than peeking at future messages, the state machine would
record internal state that indicated to throw away WM_CHAR when received after
WM_KEYDOWN.  It would also then allow direct insertion of WM_CHAR when no
WM_KEYDOWN and WM_KEYUP were received in the first place.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Eric Hughes]

Line numbers have changed; problem has not changed.  Mixing messages from an
event queue and OS calls for current state cannot possibly be correct.

Comment 3

[Stephen A Pohl [:spohl] (OOO until 9/9)]

Key event handling has changed substantially over the years. If this is still an issue, we should file a new bug.