Community
Participate
Working Groups
Steps: 1. open annotations.css - notice there are some rules flagged as empty (OK) 2. go to the last empty rule 'annotationLine' and use the quick fix to remove it (OK) 3. but now notice that the entire file has been flagged with warnings (BAD) 4. undo the quckfix, and scroll up to the top and use the quickfix to remove the 'annotation' empty rule (OK) 5. next, use the fix again on '.annotation.error' and notice that it seems to have removed part of something leaving behind 'ng' (BAD) If you keep going from point 5 (keep using the fix), the fix just seems to start removing random parts of rules, and it eventually gets you into a state that you cannot undo from.
(3) appears to be an issue with how CSSLint processes its rules, but I will investigate further. (5) is because the css quick fixes look for specific characters (and it doesn't handle the multiple lines of selectors in annotations.css), they do not use the AST to find the fix range.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=619781aa381c4ce7a4c1edff80596e7368658b35 Fixed (5) so that the regex handles selectors over multiple lines. To prevent running into this issue in the future we should use the AST to figure out the range. Added 2 tests for this case.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=f6c47aaa4cdba25ab2ea8c95d907de6c6257f22e Fixed in master Figuring out the cause of (3) turns out to be quite difficult. It looks like it is a problem with csslint having a bad config value after performing a quick fix. The actual problem is due to a timing conflict. It is possible after running a quickfix that deletes code to have the CSS hover happen before the file is validated. As the CSS hover code does not pass rule severities in, the defaults are used. The order must be: 1) Open the file so it validates normally (cache is good) 2) A TextEdit must run, in this case a quickfix removal (cache is stale) 3) Cache sees the inputChanged (cache is deleted) 4) Mouse location kicks off a hover 5) Hover asks for a parse with no rule severities (cache is bad with wrong severities) 6) Validation sees the inputChanged 7) Validation asks for a parse with the correct rules (bad cache value returned) The fix is to move the configurable severities code into CSSResultManager so we always run with the correct settings and cache the right result. A better solution would be to separate the parse from the validate in CSSLint, so hovers don't do the validation, but that would require a massive change to how we consume csslint.
Mike please verify that you can't reproduce this or any similar issues with the quickfixes. All of the quickfixes are using regex so complex selectors and rules might break them.
Looks good. I can no longer reproduce.
