Brackets freezes when searching near certain uppercase Unicode chars

[ugurbulut]

When i select a tag especially "</b>" to find another one, brackets crashes and frozen..

[peterflynn]

@ugurbulut Can you provide some more detail? Ideally, please give us specific steps that you can follow to cause the problem.

For example, here's what I tried:

1. Open index.html in the default "Getting Started" project
2. Using the mouse, drag to select a </p> tag (or a </em> tag - same result either way)
3. Press Ctrl+F to open the Find bar
4. Press Enter

This all worked as expected for me. Can you provide different steps that show the problem in this case?

Three other questions:

1. What do you mean by "crashes"? Does the whole Brackets window disappear or go blank? Does an error message appear? Does the UI stay visible but becomes frozen? If so, does Task Manager / Activity Monitor show high CPU usage?
2. What OS are you using?
3. If you temporarily remove all extensions does the problem still occur?

[ugurbulut]

Hi @peterflynn,

1. I click open a folder and choose a project folder (I'm working on .Net C# Project and choose a .aspx file)
2. I select </b> tag and use CTRL + F keyboard shortcut to find other similar close tags.
3. Bracket Editor is not responding. Top menu is working but file explorer and HTML editor is frozen. I can't write anything.

I removed all extensions, i uninstalled Brackets and do a clean installation on a other driver but nothing has changed.

I attached a file screenshot of Brackets and Task Manager.

PS: OS is Windows 7 x64 Home Premium

Thanks

[peterflynn]

Can you try disabling all extensions and see if the problem still occurs? From the screenshot it looks like you have some extensions that modify the UI, at the least (working set replaced with tab bar, perhaps? and status bar hidden), which could be causing problems.

Also, is it possible to share that one file with us so we can try to reproduce the problem? (You could send it directly if you don't want to post it publicly).

[ugurbulut]

I tried this but unfortunately nothing was changed. I think there is a problem with <b> and </b> tag. I changed all b tags to strong on Notepad++ than i reopened the file with brackets and there was not problem.

You can download the file that i am working

[marcelgerber]

I can repro this with the text file, and I even edited it to the least I can repro: <b>İİ İİ</b>. Seems to be caused by the (turkish?) chars. Does not repro with ü, for example.
It's not mode-specific, works even after renaming to .txt.

Can't repro it in CodeMirror demo.

[marcelgerber]

The problem is FindReplace : 287 : while (cursor.findNext()) {.
For some reason (maybe still CodeMirror), this is an infinite loop.

[peterflynn]

Repros as far back as Sprint 18 at least, so not an urgent regression. Will investigate more today...

[peterflynn]

Yikes, so apparently the problem is that for certain unicode strings, including "İ", converting to lowercase changes the number of characters. So str.length === str.toLowerCase().length is not always true. Similarly, str[i] and str.toLowerCase()[i] don't always match up.

It shouldn't be hard to prevent Find from going into an infinite loop here, but this has far-reaching implications covering a whole bunch of other Brackets features, including Find in Files and Quick Open / StringMatch. Adding architecture tag.

[peterflynn]

Clarified title (was: "Brackets crashes when select a close tag and run to find")

[peterflynn]

CC @RaymondLim since I know you're sometimes interested in crazy localization-related stuff :-)

[RaymondLim]

@peterflynn You got me! I was thinking of looking into this one. Have you tried with toLocaleLowerCase()?

[peterflynn]

Same problem, since that just converts using your current locale. The string changes length either way.

[peterflynn]

As noted above, I suspect a bunch of parts of Brackets would have issues with chars like this. In this particular case, the infinite loop here is caused by a bug in CodeMirror's searchcursor.js. Filed codemirror/codemirror5#2009.

If we don't see a fix for that soon, we could probably work around the searchcursor bug in a manner similar to our existing workaround in the findFirst() loop.

[marcelgerber]

@ugurbulut This bug was fixed and is included in the next Sprint of Brackets.
See codemirror/codemirror5#2009.

[ugurbulut]

@SAplayer , thanks for description.

[peterflynn]

FBNC to me to verify

[ugurbulut]

I tested this problem on the same project and same file at Sprint 37, it works great.. Thanks @peterflynn