I can't reproduce this so far -- can you try on a canary or dev channel, i.e. m51? Also, does it happen always or is it specific to particular page and/or sources?

It happens to me too, when I map the files to work on devtools

Happening on Mac OS as well. Disappears as soon as I use "Map to local resource" on a file. Any changes made to source are not preserved to a file-system.

Screenshot of canary (64-bit) 51.0.2680.0 . (Perhaps there is another problem with this: don't work "Auto-reload generated CSS" and don't auto-saved styles, changed in "Elements->Styles" (and in Canary too). Maybe it's about the same? Sorry if a lot of points in one issue - I have collapsed my workflow.)

Deleted: canary.png 51.1 KB

	canary.png 51.1 KB View Download

and it is not specific to particular page or sources.

I think I know what is wrong, but I need your help verifying it:

Could you go into the Settings -> Workspace and look at the mappings that were created for you. the way it should work:

- Lets say source file is here: "file://root/project1/main.css"
- You serve it as http://localhost:8000/project1/main.css
- You added "file://root/project1" as a workspace folder

the mapping under "file://root/project1" should be:

http://localhost:8000/project1/ -> /

for me it was

http://localhost:8000/ -> /project1/

which is the other way around and is wrong. I'm fixing it right away, but you should be able to fix things via manually adjusting your mapping settings.

Please tell me it if that helps.

Oh my God - it works (all the features returned)! Thank you! You are Great! (like "Emmet-LiveStyle" is very hell for me, and this feature is very important for Chromium like IDE).

Deleted: good.jpg 45.3 KB

	good.jpg 45.3 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ca1179ee182e37f4b70d0cce280a46ffa62ce98d

commit ca1179ee182e37f4b70d0cce280a46ffa62ce98d
Author: pfeldman <pfeldman@chromium.org>
Date: Fri Mar 18 21:21:52 2016

DevTools: automatic mapping detection is broken for cases with specific file paths.

BUG= 595347 

Review URL: https://codereview.chromium.org/1813943003

Cr-Commit-Position: refs/heads/master@{#382092}

[modify] https://crrev.com/ca1179ee182e37f4b70d0cce280a46ffa62ce98d/third_party/WebKit/LayoutTests/inspector/file-system-mapping-expected.txt
[modify] https://crrev.com/ca1179ee182e37f4b70d0cce280a46ffa62ce98d/third_party/WebKit/LayoutTests/inspector/file-system-mapping.html
[modify] https://crrev.com/ca1179ee182e37f4b70d0cce280a46ffa62ce98d/third_party/WebKit/Source/devtools/front_end/workspace/FileSystemMapping.js

Your change meets the bar and is auto-approved for M50 (branch: 2661)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3477dc0704cd415cfb2a5f19353042a390bfa458

commit 3477dc0704cd415cfb2a5f19353042a390bfa458
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Mon Mar 21 17:31:09 2016

DevTools: automatic mapping detection is broken for cases with specific file paths.

BUG= 595347 

Review URL: https://codereview.chromium.org/1813943003

Cr-Commit-Position: refs/heads/master@{#382092}
(cherry picked from commit ca1179ee182e37f4b70d0cce280a46ffa62ce98d)

Review URL: https://codereview.chromium.org/1822723002 .

Cr-Commit-Position: refs/branch-heads/2661@{#310}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/3477dc0704cd415cfb2a5f19353042a390bfa458/third_party/WebKit/LayoutTests/inspector/file-system-mapping-expected.txt
[modify] https://crrev.com/3477dc0704cd415cfb2a5f19353042a390bfa458/third_party/WebKit/LayoutTests/inspector/file-system-mapping.html
[modify] https://crrev.com/3477dc0704cd415cfb2a5f19353042a390bfa458/third_party/WebKit/Source/devtools/front_end/workspace/FileSystemMapping.js

Verified the merge on the latest M-50(50.0.2661.48) on Windows-7 and this is working as intended. Attached is the screen-shot of the same.

Deleted: 595347.png 36.5 KB

	595347.png 36.5 KB View Download

This regression affected all the DevTools Workspaces users in M49 stable. It is now fixed on ToT and in M50 branch, but the bug is still in the wild.

The fix is very local and only affects the code paths starting with the "Map to local..."  user action. This action is currently broken in M49 due to the bug this CL fixes. I'm suggesting this gets merged into stable provided there is a matching update pending.

[Automated comment] Request affecting a post-stable build (M49), manual review required.

Based on comment #14, this seems to be a safe merge and already verified by TE on M50 branch. So approving merge for M49 (branch 2623). Please merge your change in ASAP, we are planning to cut a stable candidate at 5PM PST today.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cca63001063b46c0bf57636f8cb1aab56c0ffcbb

commit cca63001063b46c0bf57636f8cb1aab56c0ffcbb
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Tue Mar 22 19:17:22 2016

DevTools: automatic mapping detection is broken for cases with specific file paths.

BUG= 595347 

Review URL: https://codereview.chromium.org/1813943003

Cr-Commit-Position: refs/heads/master@{#382092}
(cherry picked from commit ca1179ee182e37f4b70d0cce280a46ffa62ce98d)

Review URL: https://codereview.chromium.org/1825573002 .

Cr-Commit-Position: refs/branch-heads/2623@{#648}
Cr-Branched-From: 92d77538a86529ca35f9220bd3cd512cbea1f086-refs/heads/master@{#369907}

[modify] https://crrev.com/cca63001063b46c0bf57636f8cb1aab56c0ffcbb/third_party/WebKit/LayoutTests/inspector/file-system-mapping-expected.txt
[modify] https://crrev.com/cca63001063b46c0bf57636f8cb1aab56c0ffcbb/third_party/WebKit/LayoutTests/inspector/file-system-mapping.html
[modify] https://crrev.com/cca63001063b46c0bf57636f8cb1aab56c0ffcbb/third_party/WebKit/Source/devtools/front_end/workspace/FileSystemMapping.js

 Issue 592433  has been merged into this issue.

FYI another user reported similar problem here (18 days ago): 

https://github.com/google/WebFundamentals/issues/2631

I'm still seeing this issue on Version 51.0.2693.2 canary and Version 49.0.2623.110 m.  Steps to replicate:

Add a workspace - local resource mapping.
Within the Mappings section - add the web path to the resource - compliment this with the path to the local resource.  The changes to the file are persisted from being edited within the sources tab - but the elements tab now shows no line numbers - and there is no connection between the styles - and the line numbers have disappeared.

In Chrome 48, you can map a local javascript file via right-click "Map to network resource" (e.g. map the local resource Foo.js to localhost:8080/Foo.js?compile=false).  LiveEdit and debugger breakpoints then refer to the local javascript file.

I'm unable to get this to work in post 48 versions (i.e. tried 49 / 50).  I noticed in the Settings->Workspaces that 48 uses "C:\..." whereas latest versions are using "file:///C:/..."

@wayn..., @cavem...: could you respond to me privately with exact paths on your filesystem and the contents of the Settings -> workspace?

There seem to be two distinct bugs, one of them producing the larger impact, was fixed. The smaller one is described below:

It turned out that we've never supported mapping for URLs with query params well. When establishing mapping, it was creating mapping with the file (not folder) granularity. As a result, mapping worked with the selected files, the ones explicitly mapped. That worked in M48 and we removed the support without realizing it in M49.

The mapping itself was designed to operate broader terms, folders, and in order to restore the functionality, we need to teach DevTools to map

c:\foo\bar.js <==> foo/bar.js?ts=1234

Unfortunately, this is not trivial since DevTools needs to know how to convert 
c:\foo\bar.js to foo/bar.js?ts=1234 with just mapping in hand, while ts=1234 could be dynamic and volatile. So it will time to fix.

I'm glad that a fix is in the works. This causes an issue with Wordpress setups as well.

For an example, in Wordpress when a style is enqueued:

wp_enqueue_style ( 'customstyle', get_template_directory_uri () . '/css/custom.css', false, '1.1, 'all' );

... a version number is sent to the browser to ensure consistency. Chrome reads this file as custom.css?v=1.1. When trying to map this file to your local resource that of course doesn't have a version number, nothing happens. For persistence to work for me, I have to remove the version control on my local during development, then add it back when syncing to production. An extra step that leaves room for error.

The remaining part from comment #24 is being tracked by  crbug.com/596422 .