Wednesday, May 26, 2010 7:00 AM
We have an application that uses the RichTextBox control inside a DataGrid cell, and while testing for right-to-left input we have encountered a problem whereby, under certain conditions that sadly we haven't quite nailed down yet, the UI thread hangs inside the MeasureOverride method of the RichTextBox control.
It only happens when the control is right to left mode, and when the content includes InlineUIContainers. It also seems to be related to the specific content and the current size of the column. If the conditions are correct (some specific content exists in the control and the window size is set to a certian size) then it is repeatable. Changing the window size will then stop it happening.
Thursday, May 27, 2010 10:18 PM
Thanks for reporting the issue. Unfortuantelly, I'm not able to reproduce the issue. I guess it's because I miss some conditions which can cause the problem, if you get how to reproduce the problem, please let use know, thanks. And if it's possible, you can upload a sample to http://www.skydrive.com and tell use the steps that might cause the problem.
Tuesday, June 01, 2010 6:41 AM
Thanks for getting back. We are trying to produce a simple example that reproduces the problem at the moment, but it is proving tricky - it's obviously quite a subtle problem. I'll post again as soon as we have something useful.
Friday, June 18, 2010 7:33 AM
We have managed to produce a very simple sample which I have put up on skydrive.
If you run the project and click the Arabic button, and then resize the window (back and forth a few times) it will hang the browser. If you choose English, or the 'without images' options it will not crash. So the crashing seems to only happen with Right to Left languages where you have some Inline Content and you resize causing the Measure method in RichTextBox to loop infiintely.
I'd be very grateful if you could take a look.
Friday, June 18, 2010 7:44 AMThere seems to be a infinite loop occuring the internal RichTextBox's native code in MeasureOverride.
The issue doesn't seem to occur if everything is statically defined in XAML. It only happens when Runs (with RTL text) and InlineUIContainers are added programmatically to the RichTextBox model.
Also, you'll probably need to resize your window (i.e. just drag the bottom right window corner around) to a varying degree as the freeze/CPU spin problem occurs with different sizes on each machine.
Monday, June 21, 2010 3:08 AM
Thank you very much for producing the sample, I will send it to production team to have a check. If I get any feedback, I will let you know.
Wednesday, June 23, 2010 5:07 AMHi Frank,
I'm working with John on the issue and I'm the author of the sample. I was just wondering if the freeze/CPU spinning was witnessed by you or any others at Microsoft and when feedback can be expected.
Also, are there any other avenues that we should be following to inquire about the possibly of a fix?
Thursday, June 24, 2010 7:01 AMHi again Frank,
I'm finding the same issue with Hebrew text now. It seems like it could be just because of certain characters. I'm unsure.
I've created the same basic sample but with some Hebrew text
I hope this is reproducible.
As an aside, there also seems to be the same CPU spinning when GetNextInsertionPosition is called on the same bad run of text. I haven't made a sample for it but it seems related. Let me know if a sample should be created for that as well.
Thursday, June 24, 2010 7:14 AMI've now seen the announcement for creating Microsoft Connect bugs. I've created one here:
Friday, June 25, 2010 2:12 AM
The issue is reproducible on my side, but I couldn't figure out the cause, so I sent it to production team and currently I'm waiting for reply. If I get any, I will let you know.
Thanks for reporting the issue.
Monday, July 05, 2010 10:13 AMHi Frank,
This issue is very important to my company. Who can I get in touch with to escalate the issue?
Tuesday, July 06, 2010 2:56 AM
I have sent the issue to production team and they're currently investigating on the issue. It will take some time, I will get back here as soon as I get any workaround. Thanks.
Thursday, July 22, 2010 3:33 AM
Sorry for the late reply. I got some feedback from our product team. In fact, it's kind of a question for you:
The cause of the crash/hang you are seeing is that the InlineUIContainer objects have a different FlowDirection (LeftToRight) than the Arabic text (RightToLeft). We have a bug around line breaking in this case. I do have a question about this scenario though – it looks like in your app, the RichTextBox has FlowDirection=LeftToRight, which gives the inline objects also a FlowDirection=LeftToRight. The Arabic text is still rendered RightToLeft because it’s in Arabic script. Is it by design in the app to have the RichTextBox (and therefore the inline objects) be in a different FlowDirection from the Arabic text? For a true RTL scenario the control’s FlowDirection would also be RightToLeft, so that both Arabic text and inline objects are laid out from right to left.
We have a good idea on how to fix it, but no good workaround unfortunatlly. The suggestion from our product team is that:
If you can change the RichTextBox’s FlowDirection to RightToLeft, this should work around the problem since the text will not be in a different direction from the UIElements. However, the layout will be different and I’m not sure if that’s acceptable to you. Please let me know if you have questions.
Thursday, July 22, 2010 4:41 AM
Thanks for the reply. We do have scenarios in the editor we're creating that allow users to have RTL text in LTR sentences. RTL and LTR text can be mixed at will (proper names of things may not be translated between languages) and it is user selectable to present the words as RTL or LTR overall in the RichTextBox.
Knowing that the workaround is reliable is good information and we may use it as an interim solution.
You may not be able to answer this but what would the ETA be for fixing this? Is it possible it would show up in a service release?
Thanks a lot,
Wednesday, August 11, 2010 5:46 AM
Hi again Frank,
It seems that the workaround will not be acceptable as LTR text will be needed in RTL scenarios. We did see that setting the control itself to RTL and having LTR text caused the same issue.
What options does my company have to escalating the issue in hopes for an ETA on a fix? Any contact information or instructions you could give me would be great.