You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
Editor unresponsive when clicked on commented CSS while live preview is active #9002
In release 43 (OSX Mavericks), the editor becomes unresponsive when you click on a multi-line comment (that comments out a valid class/id) in CSS while having the live preview running. I tried replicating the bug without plugins and it still occurs.
@RaymondLim Cannot reproduce unresponsiveness on 64bit Ubuntu 14.04. (on master ece9bbf).
I do see a 'Unable to load live preview page' dialog; but this happens after the index.html of the Getting Started project has rendered, although the Brackets' console says this (full stack trace below), but I'm not sure what this means - other than that would probably be the file that Brackets' errors on.
@Mark-Simulacrum@marcelgerber Since you both repro'ed this earlier, would one of you mind confirming the fix before we close it? (I tested it a bit during PR review, but this was a nasty enough bug that it never hurts to get some extra eyes on it). Thanks!
Ugh, sorry -- my fault. My last suggestion for simplifying the loop was not quite right. The stopping condition needs to exactly match how TokenUtils decides whether to stop & return false or not.
Just change the loop to match movePrevToken() properly -- i.e. while (!(ctx.pos.line <= 0 && (ctx.pos.ch <= 0 || ctx.token.start <= 0)))
Same, but wrap that up in a TokenUtils.isAtStart() utility for clarity
Change movePrevToken() to more consistently stop at the start of the stream, instead of stopping one token sooner when it knows that's the last token available. (This seems more maintainable in the long run, but a tad riskier because it would affect other callers... albeit callers that are probably well unit-tested).
Activity
Mark-Simulacrum commentedon Sep 7, 2014
@RaymondLim Cannot reproduce unresponsiveness on 64bit Ubuntu 14.04. (on master ece9bbf).
I do see a 'Unable to load live preview page' dialog; but this happens after the index.html of the
Getting Startedproject has rendered, although the Brackets' console says this (full stack trace below), but I'm not sure what this means - other than that would probably be the file that Brackets' errors on.marcelgerber commentedon Sep 7, 2014
@Mark-Simulacrum That's a rather common error message, which is probably not part of the issue.
Apparently nobody knows what it means :D See #8611.
marcelgerber commentedon Sep 7, 2014
@Mark-Simulacrum I found a more reproducible recipe that works for me on Win. Could you try it?
i.htmlandi.css, with the contents:i.htmland waiti.css*/on line 4, then press Backspace againResult: The editor becomes unresponsive
marcelgerber commentedon Sep 7, 2014
git bisectpoints to @RaymondLim's c954fb4.Mark-Simulacrum commentedon Sep 7, 2014
@marcelgerber Yes, your test case does allow me to reproduce the hang. Will test the PR branch soon.
1 remaining item
peterflynn commentedon Sep 25, 2014
@Mark-Simulacrum @marcelgerber Since you both repro'ed this earlier, would one of you mind confirming the fix before we close it? (I tested it a bit during PR review, but this was a nasty enough bug that it never hurts to get some extra eyes on it). Thanks!
marcelgerber commentedon Sep 25, 2014
@peterflynn @RaymondLim I'm sorry to say, but using the files from above recipe, the bug got even worse.
Latest master (03ab969) on Win 8.1
i.htmlandi.css, with the contents:i.htmland waiti.css*/Result: The editor becomes unresponsive
peterflynn commentedon Sep 25, 2014
Ugh, sorry -- my fault. My last suggestion for simplifying the loop was not quite right. The stopping condition needs to exactly match how TokenUtils decides whether to stop & return false or not.
@RaymondLim thee potential ways to fix that:
while (!(ctx.pos.line <= 0 && (ctx.pos.ch <= 0 || ctx.token.start <= 0)))peterflynn commentedon Sep 25, 2014
@RaymondLim I can post a fix using approach 2 above -- just proofed it out.
marcelgerber commentedon Sep 29, 2014
Looks good now.
JeffryBooher commentedon Sep 29, 2014
Closing as fixed. @liaujianjie let us know if you still see problems.