Attached is a screenshot showing multiple CSS files that were added to the workspace for this page. As you can see, most of them come through just fine but 2 do not. Incidentally, these are the 2 CSS files I've worked on locally since first trying to make use of this feature. No clue why they aren't coming through. I'm on a Windows PC at the moment that is managed by my office, so any number of configuration or permission settings could be at play here.

From the previous bug, someone gave me these 2 tips:

One common reason why things might not map is caching:
- Make sure that "disable cache" checkbox is turned on in DevTools settings
- If your page has a service worker, then make sure that "bypass for network" checkbox under Application>Service Workers is toggled as well.


Cache has always been disabled for my instance of DevTools. We don't use Service Workers on this page, but I tried to find this feature to disable it, but it's nowhere in the DevTools settings.

I'm going to look further into this with a couple of personal Wordpress sites I develop on personal machines. Hopefully I'll have more luck there.

Deleted: Capture.PNG 9.3 KB

	Capture.PNG 9.3 KB View Download

Barry, thanks a lot for the report. Any chance you can share your website with me so that I can investigate the behavior?

Meanwhile, could you please attach a screenshot of network navigator as well?

This happens on the website cityoflakeforest.com. Attached is the new style.css that I'm using from my local PC. The change that you should expect is the logo in the header. In the CSS, it's on lines 507-518. I've now replicated this on 2 Ubuntu machines, and my Windows 10 workstation.

Screenshot also attached. I can't fit the entire network tab into view, but I could at least fit the one 404 error.

Deleted: style.css 106 KB

style.css 106 KB View Download

New screenshot. Sorry, cache was still enabled in the last view.

Sorry, I was unclear about the screenshot. I meant the "Network" navigator view in the Sources Panel (like the one on my screenshot), not the Network panel.

Deleted: network-navigator-view.png 32.8 KB

	network-navigator-view.png 32.8 KB View Download

Sorry about that, here's a new one

Deleted: Screenshot_2017-03-30_18-10-36.png 116 KB

	Screenshot_2017-03-30_18-10-36.png 116 KB View Download

nice, thanks! AFAIU, you'd expect the network file "style.css?g=mRcMjz1P..." to map against the file system "style.css".

Which one did you attach at comment #3? Could you please also attach another one for me to compare them?

Yes, I'm expecting http://www.cityoflakeforest.com/cms/includes/style.css?g=mRcMjz1POLEsbxvdE1TSQDdRXZ3Ght5CrUcYu5mKsu8Ytgl2mlQKSMP6oYUPzpAO to map to my local copy of "style.css". My local copy of "style.css" with a single change I'm trying to make is attached in #3

Hmm, that's interesting.

So you have your website running in the cloud, and you have a copy of your website locally. As you make local changes, your website doesn't actually update until you "deploy" your changes to the server. Is this correct?

Not quite, I don't think I'm explaining this correctly. The live version of the site is what I linked above. I normally work on a development copy that's hosted internally. We check code in/out for revision history, but I'm not running the site locally. I'm testing my changes using Chrome's DevTools, but I'm hoping to make use of this new Persistence2.0 feature so that I can also manage the code I've checked out.

Does that help?

The bug with Persistence2.0 happens on both copies of the site and on all my copies of Chrome, so maybe it's just something with this particular site? I haven't had a chance to work on this feature with other sites just yet.

Persistence2.0 works by matching your local files to the network ones by their content.

So in your case, since the local version of style.css is changed, and since the upstream version doesn't have any changes, we don't establish mapping. This is to ensure predictable results.

For your scenario to work with persistence2.0, you would need to serve your website locally.

Another option might using good old "save as" option for the changed file. Note: once you've picked a "save as" file, devtools will keep saving into it until reloaded.

 Issue 708989  has been merged into this issue.

This Persistance 2.0 is ignoring some common use cases:

* Website or apps hosted on a internal server
* Css saved from a admin panel (like Tumblr, Shopify e etc)
* Frameworks that by security reasons change assets paths and names

Is it possible to disable on Canary?

I'm in my second week where I have reinstall an older version of Chrome everyday.
I have 4 co-workers in the same situation.

I don't understand. If the mapping breaks as soon as I change the contents of a file then what is the point of this feature? If the mapping only works when the local version of a file matches the hosted version, why would I bother to map to a local folder at all?

@manobi, @barry: we completely overlooked these scenarios. We are really sorry about
that! We are bringing mappings back.

A few questions so that we better understand what's going on: 
- overall, you use devtools "workspace" to override website style sheets - is this correct?
- do you care only about CSS editing?
- do you use sourcemaps for CSS?

Revert Started: https://codereview.chromium.org/2818713007/

It would be nice to merge it back to M58 and M59 as it lands.

Since I'm not able to upload sourcemap files to the e-commerce sites I work with. I don't use source maps.

That is it, I use the mapping to override the current css without having to upload the file for every update.

I'm Stylus to generate my css files, if there was a way to use sourcemaps without having to upload it to the remote server (only available on my computer) it would be awesome.

In what release do you think it will be reverted? on canary? when?

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

commit 3c24f4f7064cb6fcf8827bd5bd29ec12664dbd3d
Author: lushnikov <lushnikov@chromium.org>
Date: Tue Apr 18 06:20:34 2017

DevTools: fix tests to ensure clean revert of persistence2.0

This patch is a preparation for the https://crrev.com/2818713007 to unbind
persistence2.0 behavior from tests.

This patch:
- enables persistencd2.0 by default in persistence-do-not-bind-dirty-sourcecode.html
  because the test verifies the binding prevalidation behavior
- fixes bug in JavaScriptSourceFrame which used wrong uiSourceCode (that's
  inevitable)

BUG= 707002 
R=dgozman

Review-Url: https://codereview.chromium.org/2826573002
Cr-Commit-Position: refs/heads/master@{#465153}

[modify] https://crrev.com/3c24f4f7064cb6fcf8827bd5bd29ec12664dbd3d/third_party/WebKit/LayoutTests/http/tests/inspector/persistence/persistence-do-not-bind-dirty-sourcecode.html
[modify] https://crrev.com/3c24f4f7064cb6fcf8827bd5bd29ec12664dbd3d/third_party/WebKit/Source/devtools/front_end/sources/JavaScriptSourceFrame.js

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

commit 87e05d141b5b873725e95585e92f07a6b7ac1fb2
Author: lushnikov <lushnikov@chromium.org>
Date: Tue Apr 18 23:03:19 2017

DevTools: revert Persistence2.0 experiment by default.

It turned out that Persistence2.0 doesn't account for the important
usecase: develoers were using workspace feature to override hosted
stylesheets.

In this case, both Persistence2.0 and "prevalidateBindigns"
experiments stay on their way:
- Persistence2.0 doesn't allow to map files with different filenames
- prevalidateBindings doesn't allow to map network resources to files
  if contents are different.

This patch:
- disables Persistence2.0 experiment by default
- merges prevalidateBindings experiment into Persistence2.0 experiment

The latter is important since binding prevalidation only necessary for
Persistence2.0 to work properly.

BUG= 707002 
R=dgozman

Review-Url: https://codereview.chromium.org/2818713007
Cr-Commit-Position: refs/heads/master@{#465412}

[modify] https://crrev.com/87e05d141b5b873725e95585e92f07a6b7ac1fb2/third_party/WebKit/Source/devtools/front_end/help/ReleaseNoteText.js
[modify] https://crrev.com/87e05d141b5b873725e95585e92f07a6b7ac1fb2/third_party/WebKit/Source/devtools/front_end/main/Main.js
[modify] https://crrev.com/87e05d141b5b873725e95585e92f07a6b7ac1fb2/third_party/WebKit/Source/devtools/front_end/persistence/Persistence.js

@manobi: the revert of persistence2.0 should hit canary soon.

It would be nice to merge #20 into M-58 and M-59.

This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

M58 for Desktop is already went out to Stable yesterday. At this point we're only taking critical merges in for future stable refresh (if any).
 
This is P2 bug,  issue 708989  listed at #12 was reported on M57 (not an M58 regression) and per comment #21 it would be nice to merge it is not absolutely needed. So I'm leaning towards not to take this merge in for M58. Please let me know if there is any concern here.

There is a person on my team that do not power off his computer for a week to no let Chrome Update and break network mapping.
There is also one co-worker so as myself who have to uninstall Chrome for mac and install an old .dmg everyday to work.

Is it already in Canary, if you can put it at least on Canary I will be able to help my team.

@manobi: the revert is in Chrome Canary.

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

commit cc83cecb8fa8b3385610f2dd893166acbedbd8da
Author: Andrey Lushnikov <lushnikov@chromium.org>
Date: Thu Apr 20 21:28:56 2017

DevTools: revert Persistence2.0 experiment by default.

It turned out that Persistence2.0 doesn't account for the important
usecase: develoers were using workspace feature to override hosted
stylesheets.

In this case, both Persistence2.0 and "prevalidateBindigns"
experiments stay on their way:
- Persistence2.0 doesn't allow to map files with different filenames
- prevalidateBindings doesn't allow to map network resources to files
  if contents are different.

This patch:
- disables Persistence2.0 experiment by default
- merges prevalidateBindings experiment into Persistence2.0 experiment

The latter is important since binding prevalidation only necessary for
Persistence2.0 to work properly.

BUG= 707002 
R=dgozman

Review-Url: https://codereview.chromium.org/2818713007
Cr-Commit-Position: refs/heads/master@{#465412}
(cherry picked from commit 87e05d141b5b873725e95585e92f07a6b7ac1fb2)

Review-Url: https://codereview.chromium.org/2834493005 .
Cr-Commit-Position: refs/branch-heads/3071@{#100}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/cc83cecb8fa8b3385610f2dd893166acbedbd8da/third_party/WebKit/Source/devtools/front_end/help/ReleaseNoteText.js
[modify] https://crrev.com/cc83cecb8fa8b3385610f2dd893166acbedbd8da/third_party/WebKit/Source/devtools/front_end/main/Main.js
[modify] https://crrev.com/cc83cecb8fa8b3385610f2dd893166acbedbd8da/third_party/WebKit/Source/devtools/front_end/persistence/Persistence.js

This is merged back into M-59.

As per offline discussion, we won't merge this into M-58 because it's too risky. 
All the affected users can now use M-59/M-60 (Canary) as a workaround to get the old persistence.

Thank you  lushnikov@. Rejecting merge to M58 based on comment #28.