New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 863408 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit 28 days ago
Closed: Dec 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

DevTools saving local style changes (via Styles panel) to generated CSS file despite workspaces being setup and SCSS being used

Reported by tenlet...@gmail.com, Jul 13

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. Setup your workspace
2. Test whether changes to the SASS file via Sources panel work fine
3. Make a change to an element in the Styles panel directly
4. Reload the page and see if the change persists
5. If so, check the CSS file that was generated by SASS and that is used by Chrome for the site: the change will be saved in there
6. Check the SASS file itself (SCSS) – the change will not be made in that file

What is the expected behavior?
Chrome should either:

1. Not save any changes from the Styles panel directly to the CSS file
or
2. Save the changes to the correct SASS file instead

Chrome should offer an option to let the developer choose whether to save styles directly and whether to save them to the map-linked source-file. Chrome should not make changes to a CSS file that is being overwritten on the next change of the SASS file anyway. It makes no sense!

What went wrong?
Changes to elements via the styles panel are being saved to previously auto-generated CSS files. These changes persist throughout page reloads (of course, since written to CSS) but make no sense because once the underlying SASS file is changed, the changes will be reverted /overwritten.

Did this work before? N/A 

Chrome version: 67.0.3396.99  Channel: stable
OS Version: OS X 10.13.5
Flash Version: 

Great work on the Source Map / CSS Live Edit feature. I think you guys should provide some very clear documentation on how this works.
 
Labels: Needs-Triage-M67
Cc: vamshi.kommuri@chromium.org
Labels: Needs-Feedback Triaged-ET
Thanks for filing the issue!

@Reporter: Could you please share a sample test file/URL which helps to triage it further in a better way. 
I too am experiencing this problem. Although Chrome does persist changes, it persists them to the COMPILED / dist version of CSS and not the actual mapped source .css/.less/.scss file.

I have provided a fork where you can see the problem: https://github.com/garygreen/chrome-persist-css-problem

1. Clone fork
2. Open test.html
3. Add Workspace to Chrome
4. Open dev tools, change a css property on the "testing" text
5. Notice that the changes persist in the dist/main.css file however they do not get persisted in "site.css" which should be the actual mapped file.

persist.gif
290 KB View Download
chrome-version.PNG
10.9 KB View Download
Owner: lushnikov@chromium.org
Status: Assigned (was: Unconfirmed)
Status: WontFix (was: Assigned)
Editing styles through styles sidebar pane is changing the CSS file - the change doesn't propagate to the original mapped source.

We used to have the "LiveSASS" experiment a while ago that would propagate changes back to SASS/sourcemapped CSS. The experiment was eventually deprecated and removed due to no clear path forward.

All in all, this works as intended.

Sign in to add a comment