Bug 477383

Created attachment 273701 [details]
Test Case

This should be fixed in rev 127819. Could you confirm (or not)? Thanks!

This is working now, thanks!

Before I forget -- can this and #477395 be backported to mono-2-4?

hi Brad, I do as your "Steps to reproduce", it seems that characters in MaskedTextBox can't be deleted by the Backspace key.

REPRO for our sample :
1.  Run uia2atk/test/samples/maskedtextbox.py.
2.  on sample GUI , insert characters "dfafsdfasf" or "ilikeit " into the fourth MaskedTextBox accessible.
3.  Press Backspace key

Output:
the characters can't be deleted, until you use 'left' Key to navigate the cursor in front of the character then you can use "delete" Key to delete it. 

test on:
mono-core-135601-1177.src.rpm
mono-uia-132785-276.src.rpm
uiaatkbridge-134036-662.src.rpm
uiautomationwinforms-134512-668.src.rpm
Revision: 135906

In rev 135925 I can use the backspce key to remove the chars in the fourth text box. Is therey any chance you could test directly with the svn version instead of the rpms? I suspect they could somehow be showing different results.

hi Carlos,
The latest mono-core version is 135601, so I update the WinForm the latest version, and it still can't delete the character by enter the Backspace key, but I will retest it when the mono-core's version is updated.

Any new regarding this bug?

Carlos, I retest this bug on:
mono-core-136889-1329.src.rpm
mono-uia-132785-276.src.rpm
uiaatkbridge-136162-663.src.rpm
uiautomationwinforms-136380-671.src.rpm
Revision: 136914

this problem still happens, and for the editable table cell in propertygrid has the same problem, please see the bug 513097.

Felicia, this works for me and has worked since Carlos committed his fix in February.

I'm going to go ahead and close this, and the two of us can work it out over email or on IRC.  I suspect you're running the 2.4 branch of mono, not mono trunk.

Hi Brad, on my computer and other co-workers' computer it still doesn't work and I still not find the reason why it shows the difference.(I'm running the mono trunk)

our version is :mono-core-137213-1365.src.rpm
mono-uia-132785-276.src.rpm
uiaatkbridge-136162-663.src.rpm
uiautomationwinforms-136380-671.src.rpm
Revision: 137227

Hardware: i586
OS: openSUSE 11.1

Felicia, lets please talk about this together over email instead of spamming this bug.  Thanks.

Created attachment 306046 [details]
code to output some log and demostrate the root cause of the bug

I can reproduce this bug easily on Felicia and Ray's notebook(both of
them are Dell D630), on both mono r137183 and mono trunk. However, on
other two Dell D630, I cannot reproduce the bug on them, really weird.

The 4 Dell D630 all installed open suse 11.1, and the versions of
"xorg-x11-server" are all 7.4-14.7.1.

And  I found the the bug is originated from the XLookupString P/Invoke in X11Keyboard.LookupString. (this native API just don't return the same result with same input arguments at different time)

in detail:
The MWF keyboard event processing procedure on X11:
in X11Keyboard.TranslateMessage, the source will post a WM_CHAR
message if the return value of "ToUnicode" is 1, and make the "buffer"
var be the message's wParam, and in most cases the "buffer" is
assigned in "ToUnicode" accroding to the value of "lookup_buffer", and
the "lookup_buffer" is assigned by the "XLookupString" native API,
which is called by "LookupString".

And as I watched, the problem happens when "XLookupString" didn't
assign the sound value to lookup_buffer, so that "ToUnicode" will not
return the correct value, and the "buffer" var is not correctly set in
X11Keyboard.TranslateMessage, so that the expected WM_CHAR (with
wParam equals to 8, which is the code for backspace key) message is
not generated, so that TextBoxBase.HandleBackspace will not be
invoked.

To demostrate the problem (firslty u need to find a machine which has
backspace problem on MWF), u could apply the following patch on
X11Keyboard.cs in SWF, and then compile and run a Textbox sample, and
then hit backspace in the TextBox. On a normal machine the output will
be:

Evt: 22, 16, True, False, 26716165, 2397, 127, 138777296, 0, 111149117
Non-XIC: XK_BackSpace, 1, [], 24
Evt: 22, 16, False, False, 0, 0, 0, 138777296, 0, 0
Non-XIC: XK_BackSpace, 1, ], 24
UTF.LookupString: XK_BackSpace, 0, ]
which means after XLookupString is invoked, the returned lookup_buffer
is "/b" (/b means the backspace char)

however on a problem machine, the output could be:

Evt: 22, 16, True, False, 26786491, 5327, 127, 138777296, 0, 111149117
Non-XIC: XK_BackSpace, 1, [], 24
Evt: 22, 16, False, False, 0, 0, 0, 138777296, 0, 0
Non-XIC: XK_BackSpace, 1, [], 24
UTF.LookupString: XK_BackSpace, 0, []

which means after XLookupString is invoked, the returned lookup_buffer
is "". Actually on Felicia's machine the returned lookup_buffer could
be any kind of value, e.g. I've watched once the length of the
returned lookup_buffer is 4.