I found a report of a case recently where Regex Hero would sporadically cause Chrome to crash. It was in a comment on StackOverflow, and I'm lucky to have found it. I didn't have much to go on, but I take reports like this seriously.
First of all, I had never seen this actually happen before. But I began by banging on things trying to make anything and everything break that I possibly could. My method is perhaps a bit crude and it simply takes time and some knowledge of what's going on in the code to get anywhere.
Here's what I managed to fix, in order of discovery:
First of all, I had never seen this actually happen before. But I began by banging on things trying to make anything and everything break that I possibly could. My method is perhaps a bit crude and it simply takes time and some knowledge of what's going on in the code to get anywhere.
Here's what I managed to fix, in order of discovery:
- There was a layout problem involving the minimum vertical height of Regex Hero. After you shrink the window beyond a certain point a scroll bar appears so as not to fold the UI on top of itself. Well there was a logic problem in this calculation which could actually throw an error in certain circumstances. The error was being trapped though, and couldn't have caused the crash.
- The expand/collapse options button along the right hand side of the app had an unusual bug where, after clicking, the tooltip would be reused for other UI elements. I fixed it by using just one button rather than hiding/showing two different ones. Again, this was a weird bug but not one that could've caused the crash.
- Whenever you right click text and choose Cut/Copy/Paste, Regex Hero accesses the clipboard programmatically. On first use, this will throw a security warning from Silverlight (there's no way around that). The trouble is that if you choose not to allow Regex Hero access to the clipboard, Regex Hero would kind of fall on its face and not handle that condition gracefully. Again, an exception would be thrown, but it was caught and couldn't have caused anything to crash. I improved this process a bit and I now provide a follow up dialog.
- I took a couple days and came back to this. And just yesterday I finally reproduced the problem. The problem, it turns out, comes from another bug in the RichTextBox. And it's not isolated to Chrome. The same behavior occurs in IE9. Regex Hero was programmatically replacing line feeds with carriage returns when loading your previously stored text from isolated storage. I do this to ensure consistent behavior within the app. A separate string variable assigned to the text value of each textbox is then reshaped as necessary depending on if you have the CrLf option checked within Regex Hero. However, if you have more than 10 lines of text, then cut the top 9, then hit undo, the built-in undo functionality fails. The RichTextBox undo system seems to have a serious problem with carriage returns. It can't seem to fully restore from its history, only actually rendering 3 lines of text. The rendering pipeline then seems to be out of sync with what the text value actually equals. It's odd. And it causes Silverlight to freeze, sometimes bringing the whole browser down. I'm reporting this to Microsoft. My solution is to now replace all carriage returns with line feeds instead. Behind the scenes we have the same effect and the app works as it should, but it effectively avoids this bug.
Comments
Post a Comment