This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Download and open the project from http://wiki.netbeans.org/wiki/images/e/ee/SourceMapsExample.tar.gz 2. Run it in Chrome with NetBeans integration 3. In Chrome, enable Select mode and select the 4th (last) rectangle 4. In the CSS Styles window, change the width property to e.g. 30em - this will be reflected in the page and the rectangle will get smaller 5. Open the style.scss file and in #test2, change background-color to red. => The background color will be changed as expected, but the width of the 4th rectangle will be reverted to the original value (40em) - this is not expected. The problem is that the CSS Styles window works on top of the CSS file generated from SCSS, and this file will be overwritten when the user changes the original SCSS file. While at some level this behavior makes sense, it is unintuitive. The suggested solution is either to: - Make the CSS Styles window read-only for CSS files generated from SCSS/LESS, or - Alert the user that the changes are not persistent, and while it may be useful to tune the layout this way, the CSS file will be overwritten once the user edits the SCSS file.
Assuming we go to the latter solution "Alert the user that the changes are not persistent" - let's call this solution 2 - there is a further consideration: The development workflow with this solution is similar to that of Chrome Developer Tools (and other browser tools), but there is one important difference: in CDT, any changes the user makes will be thrown away as soon as the user reloads the page, or closes the present tab and opens the page again in a new tab. That will not be the case with our solution 2: as the changes are persisted in the CSS file, reloading the page will still show the page with user modifications, and only when the user edits the original SASS file, these changes will be lost. One could say that the application with used edits in the generated CSS file is in an inconsistent state, and the user may not notice this fact for a long time. So she may for example unwittingly commit the application to version control. I can imagine a couple solutions to this problem: solution 2a: When editing generated CSS files via the property sheet, only reflect the changes in the target browser and do not propagate them to the CSS source. Not sure how easy/feasible this solution is for 7.4. Also, this solution does not help if the user edits the generated CSS in the code editor (although this may be considered a very minor issue). solution 2b: Display a more visible alert when there are any user edits in the generated CSS file - this could be implemented e.g. using the Project Problems facility. So when the user edits the generated CSS file from the IDE (either using the property sheet or by the code editor), display a project problem for this, and keep this problem there until the CSS file is regenerated from the original SASS. The IDE could offer a "fix" for the project problem that would run the SASS compiler to generate the CSS. Any other ideas?
I have implemented a minimal version of solution 2. When properties of a generated rule are displayed in Rule Editor then there is a warning at the top of the editor saying that the rule is generated and that all changes to properties will be lost once the rule is regenerated. Modified files: http://hg.netbeans.org/web-main/rev/f3be8be5629a http://hg.netbeans.org/web-main/rev/a6c19a5ba789
Solution 2a would require significant modifications in the handling of changes in Rule Editor and in CSS reload. It is also not clear what should happen when the user edits the generated CSS file (that doesn't contain the changes done through Rule Editor). Moreover, the solution suggests a different behaviour of Rule Editor for some (=generated) rules. This can be even more confusing than the current clearly defined behavior. Solution 2b is better defined than Solution 2a but it seems a bit aggressive to me. It is like marking a Java project as having a problem when there is a modified Java file that hasn't been compiled yet. Personally, I would prefer to wait for some user feedback to see if users run into this situation, whether they will consider it problematic (despite editing the rule after seeing a warning) and what solution/behavior will they expect.
(In reply to comment #2) > I have implemented a minimal version of solution 2. When properties of a > generated rule are displayed in Rule Editor then there is a warning at the top > of the editor saying that the rule is generated and that all changes to > properties will be lost once the rule is regenerated. I believe this kind of solution is satisfactory - warn the user somehow that the changes being made are going to be lost at some point, but not restrict the user from doing the changes. I'm not sure about how the warning should look like in particular, I think this is the case when Liza could help. As for manual editing the generated file - I must say I quite like Petr's proposal of showing a a hint at the very first line saying sg. like "You've changed a generated file, the changes will be lost once you change the primary source." + hitfix with would do the regeneration. The hint may be or may not be badging but will definitively show up in action items (tasklist).
I am closing this issue as fixed because the described minimal approach has been implemented for NB 7.4 and there is issue 229525 about post-7.4 enhancements.