Bug 490130

This is definitely interesting.  Although I cannot replicate the crashing problem, I am definitely seeing weird behavior.  The weird behavior that I am seeing is that when holding down a key to insert a lot of text, all of the text in the sample application and in Accerciser's "Text" field disappears and the text being inserted starts from the beginning again.  However, this behavior seems to be caused by the fact that the character is being inserted too rapidly.  For example, when I insert a character repeatedly into Accerciser's "Text" field without letting up on the key, that is when I begin to see problems once a lot of characters have been inserted.  However, if I input the characters by tapping the key repeatedly (i.e., not holding the key down), I do not see the problem.

One thing you can try to replicate is to do the following:

1.  Open uia2atk/test/samples/richtextbox.py
2.  In Accerciser, browse to and select the text accessible representing the lower textbox in the sample application
3.  In Accerciser's IPython Console run the following:

eti = acc.queryEditableText()
eti.insertText(18, <a 2500-character string>, 2500)

4.  In Accerciser's Interface Viewer -> Text field, tap a key repeatedly (i.e., do not hold the key down) 100 or so times.  I was not seeing any weird behavior when doing this.
5.  In Accerciser's Interface Viewer -> Text field, hold a key down until weird behavior occurs.  I saw weird behavior soon after doing this each time (within a few seconds).

I will attach the 2500-character string.

This is a weird enough case that I'm not sure how much we should worry about it.  However, I could not replicate any problems (other than things slowing down dramatically) when running these steps.  

I am marking this as a P4 for now, but I'm CCing Brad because it is crashing for Felicia.

Created attachment 283002 [details]
2500-character text file, referenced in Comment #1's repro steps.

Oops!  In my second-to-last paragraph in Comment #1, I meant to say that I could not replicate any problems (other than things slowing down dramatically) when running these steps in Gtk.

I can reproduce both crashing problem and text bing inserted start from the beginning again problem. I got the same exception as Description when I holding down a key to insert about 531 texts.

hi Brian , if you cannot replicate the crashing problem, maybe there's another way:
1.  Run uia2atk/test/samples/richtextbox.py.
2.  Open Accerciser and open the "IPython Console."
3.  In Accerciser, browse to and select the second richtextbox accessible.  It
has a blank name and the "text" role.  
4.  In the IPython console, run the following lines: 

    eti = acc.queryEditableText()
    eti.insertText(18,"a",1)

    the output of the second richtextbox is :"This is some text.a"

5.  In the IPython console, run the following lines: 
                                                 
    eti.insertText(19, 123456789*"b", 123456789)

    the output of the second richtextbox is :"This is some text.a" (the output is not correct), and about 2 or 3 seconds later, the sample application crashed.

the log on the terminal is:
currentFont:  [Font: Name=Arial, Size=8.25, Units=3, GdiCharSet=1, GdiVerticalFont=False]
newFont:  Bold
Traceback (most recent call last):
  File /usr/src/packages/BUILD/uiautomationwinforms-1.0+129584/UIAutomationWinforms/Mono.UIAutomation.Winforms.Behaviors/TextBox/ValueProviderBehavior.cs, line 128, in PerformSetValue
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/RichTextBox.cs, line 755, in set_Text
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs, line 656, in set_Text
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextControl.cs, line 1973, in Insert
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextControl.cs, line 1996, in Insert
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Line.cs, line 437, in InsertString
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Line.cs, line 404, in Grow
  File richtextbox, line unknown, in Initialize
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 740, in Run
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 761, in Run
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 891, in RunLoop
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs, line 725, in GetMessage
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs, line 4490, in GetMessage
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIDriver.cs, line 492, in ExecuteClientMessage
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System.Threading/ExecutionContext.cs, line 140, in Run
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System.Security/SecurityContext.cs, line 150, in Run
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIDriver.cs, line 479, in ExecutionCallback
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/Delegate.cs, line 402, in DynamicInvoke
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/MulticastDelegate.cs, line 71, in DynamicInvokeImpl
  File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/Delegate.cs, line 430, in DynamicInvokeImpl
StandardError: Exception has been thrown by the target of an invocation.
Segmentation fault

Weird.  I wonder if event handling can be re-entrant.

This is definitely a re-entrancy problem.  Let me summarize my thoughts here:

 - Accerciser calls insertText which comes over on to our side via TextBoxEntryView.InsertText
 - The adapter hands it off to EditableTextImplementorHelper
   - Line 119 queries for the text before setting the value.

In certain cases, when S.W.F's TextBoxBase:set_Text is doing its magic:

				if ((value != null) && (value != "")) {

					document.Empty ();

					document.Insert (document.GetLine (1), 0, false, value);
							
					document.PositionCaret (document.GetLine (1), 0);
					document.SetSelectionToCaret (true);

a get_Text call can interrupt it, and does between document.Empty() and document.Insert().  This makes the EditableTextImplementorHelper.InsertText set an _empty_ value.

The solution is either to wrap the SWF code in a lock, or more globally, to lock around all potentially re-entrant methods in the Bridge.  This would be best performed by compile-time IL injection or runtime SRE wrapper classes.

Unassigning as we're focusing on the 2.0 work atm.