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

Issue 277885 link

Starred by 60 users

Issue metadata

Status: Fixed
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

DevTools: Workspace: Support urls with variable suffix in mappings

Reported by, Aug 23 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.35 (KHTML, like Gecko) Chrome/27.0.1444.3 Safari/537.35

Steps to reproduce the problem:
1. Add a new Workspace
2. Enable "Enable CSS source maps"
3. Enable "Auto-reload generated CSS"
4. Map a network SCSS resource to a local resource
5. Visit a page referencing the stylesheet with a query string
6. Update a stylesheet property in the Sources panel
7. Save

What is the expected behavior?
The page's styles should refresh upon saving the SCSS stylesheet in the dev tools.

What went wrong?
This works: <link href="stylesheet.css" rel="stylesheet">
This doesn't work: <link href="stylesheet.css?foo" rel="stylesheet">

Did this work before? N/A 

Chrome version: 31.0.1608.0 canary  Channel: canary
OS Version: OS X 10.8.4
Flash Version: Shockwave Flash 11.8 r800

Is this at all related to: 

Comment 1 by, Aug 23 2013

For some additional context, the reason we have a query string on the end of the path is because we're using a version of Rails' asset pipeline that appends a date-based query string in order to bust user agents' caches when the files are updated.
Status: Assigned

Comment 3 by, Aug 28 2013

Summary: DevTools: Workspace: Support urls with variable suffix in mappings (was: Generated stylesheets referenced with a query string don't reload when saved in the Sources panel)
 Issue 253894  has been merged into this issue.
See also  issue 108202  With DeveloperTool.Workspace, breakpoint doesn't work for url with param

Comment 7 by, Oct 19 2013

This is reproducible under Windows 7 x64 Ultimate as well, so I'd assume it is a bug on all platforms.

Cache busters/version control query strings are very popular nowadays, so this would be really nice to get fixed/patched.
Could we add an option to wildcard the querystring?

Comment 9 by, Nov 22 2013

Any progress on this? Talking to people and they're using a git commit hash to cache bust, but thus can't link through workspaces.

A filter to ignore the query string would be super useful.
Labels: -OS-Mac OS-All
@vsevik do we want to do this on the back end where I did the # fix? See  issue 306239 . It means we would never see the original network URL on the script.

Remy, do you know of other bugs related to querystring or only this one about mapping to files for workspace?  Do you think devs ever id different JS sources only by query strings?  Seems rare if they do.
query string in urls also throw off debugging break points, etc. i.e. you set a break point, reload the page and now your break point is gone because the script url has a different cache-busting query string parameter in it.
 Issue 262127  has been merged into this issue.
See  issue #242847  as well

Comment 14 by, Feb 18 2014

+1 for this. we use cache busting querystrings at too. Thanks.

Comment 15 by, Feb 21 2014

+1 for this. we use cache busting querystrings

Comment 16 by Deleted ...@, May 10 2014

+1 for this too, MediaWiki is also doing this.
+1 for this! Drupal also present this behaviour.
No news? This make the resource mapping unusable.

Comment 19 by Deleted ...@, Feb 6 2015

I know in Chrome v40.0.2214.111, GET params are no longer considered in workspace mappings.  I think this fixes the issue for most people in this thread.  Drupal uses the 'q' param as part of it's path.  However, it also supports using real paths instead.
No, does not works on 40.0.2214.111 (on Windows 7, in case this matters).

Comment 21 by Deleted ...@, Feb 7 2015

You are right, I was confused with something else.  +1 again!
We need mapping not only for CSS but JS too, as we add timestamp in all our JS files and we're unable to map them because of that querystring. We always get "workspace mapping mismatch"

Comment 23 by, Jun 28 2015

Meteor has the same query strings in it's files. We really need something like wildcards to enable mapping correctly.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!

Labels: Hotlist-LiveEdit
Status: Untriaged
Status: WontFix
Status: WontFix.

Asking for a reason is too much?
Status: Assigned
Sorry. This is still open 

Comment 30 by, Feb 18 2016

and this? it also got archived:

Comment 31 Deleted

Network mapping does not work on a Drupal site or a Wordpress site. 
Stable ver 49.0.2623.112 or Dev 50.0.2661.66
OS X 10.11.3

Comment 33 by, May 9 2016

I'm not sure why this is marked "won't fix". This is a very common scenario that breaks js and Css. 

I'm willing to take a stab at this if it's still up for grabs. 
It's no longer wontfix, but open.

nojvek: If you'd like, you can start looking into this. Let's assume there will be a setting in the Workspaces config that allows for ignoring querystring for mapping purposes.

Comment 35 by, May 9 2016

Should there be a setting though?

What's the scenario when you want a .js or .css file not query ignored?
There's two usecases for querystring we need to consider

1. The cachebust: file.css?23o22039239
2. The coldfusion: serve.asp?servefile=file.css&nocache=true&blah

Currently, it's unclear how workspaces can work for the coldfusion usecase, but that's what leads to my hesitation about blanket-ignoring the query-string.

Comment 37 by, May 11 2016

I was suggesting that we only solve the cache busting scenario. I.e
specifically only files with css and js extensions have their query params

Everything else is considered a cold fusion scenario and behaves as a new

Let's give it a go
 Issue 622689  has been merged into this issue.
Until the patch lands, you can configure a local redirect to the URL with the query string removed.  I'm using the chrome extension Requestly:

It'd be great if we could eventually use wildcards in the workspace mapping, or even regexes!
Everyone: please, try "Persistence2.0" experiment. It figures out mappings automatically and handles cache busting URL suffixes properly.
 Issue 691296  has been merged into this issue.
I can't find this experiment in Canary?
What's your canary version? Works for me on chrome 59.
40.6 KB View Download
Ah right. I was looking at Chrome experiments. Got it. Is there documentation for any of the experiments to explain what they do?

And where is the best place to ask questions like... what happened to auto reload generated CSS option?
No, there's no documentation about experiments until they're released.

Regarding the auto-reload generated CSS option - it shouldn't be needed with workspace any more, devtools auto-reload CSS by default.

Generally speaking, all kind of questions could be asked in devtools googlegroup:!forum/google-chrome-developer-tools

Also, feel free to file bugs if some functionality is missing for you!
Much appreciated!! My team have filed a few bugs recently. Thankfully they seem to be mostly fixed now.

I thought that might be the case... it seems to be working for me sometimes, but not all the time. I'll see if I can work out what the problem is.
Persistence 2.0 fixes this nicely!  It's a bit "magicky" (I feel like I have less control over mapping), but I won't complain until I can't get it to work.  For instance, I had to move a 'style.css' into a directory with the rest of my css files (in 'css/') before DevTools picked it up for persistence.

In all, very happy with this!  Kudos.
Project Member

Comment 50 by, Mar 29 2017

The following revision refers to this bug:

commit 6b74f6642be4ca9d5af4de7dcc56ea58c3f62e53
Author: lushnikov <>
Date: Wed Mar 29 18:35:34 2017

DevTools: prepare tests for Persistence2.0 release

We have a bunch of tests which rely on DefaultMapping to test
Persistence layer. However, they don't test the DefaultMapping
behavior - instead, they want to test the Persistence layer and everyone
who depends on it.

This patch:
- adds a simple TestMapping which controllably adds and removes persistence
- moves majority of the tests over to TestMapping
- removes a few tests which were testing themselves

This is a pre-step to enable Persistence2.0.

BUG= 277885 

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


#49: could you please explain your use case and file a bug separately? We'd like to add "magic" for as much usecases as possible
Project Member

Comment 52 by, Mar 29 2017

The following revision refers to this bug:

commit 7a9ca6839f01ad26a41816f4d91a404a0ad49a62
Author: lushnikov <>
Date: Wed Mar 29 20:14:25 2017

DevTools: enable persistence2.0 experiment by default

This patch enables persistence2.0 experiment by default, which results
in the following changes:
- automapping will be enabled by default for all workspace users
  (automapping design doc:
- a new UI for workspaces will be enabled by default for all workspace

BUG= 277885 

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


Status: Fixed (was: Assigned)

Comment 54 by, Mar 29 2017

Labels: DevTools-Release-Notes-Feature
I'm having the same issue that's originally reported by this bug, but "Persistence 2.0" is not pulling in the changes from my local version of a file (style.css in this case). I followed the steps to enable the experiment, restarted Chrome, mapped my local folder, but nothing changes. The new UI doesn't provide much feedback, so I don't know if I'm doing anything wrong. Is there anything I need to do after mapping my local folder, or should this "just work"?
Forgot to mention what I've replicated this under:
Windows 10 - Chrome 57.0.2987.133
Ubuntu 16.04 - Chrome 59.0.3053.3
Barry, indeed, we lack indication of why mapping fails. We're working on adding it.

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.

I created a separate bug to discuss your case in details: .
Project Member

Comment 58 by, Apr 20 2017

The following revision refers to this bug:

commit bafdd183fcee7aa3354babad88f464e3b9810cd8
Author: lushnikov <>
Date: Thu Apr 20 04:53:11 2017

DevTools: [Workspaces] remove support for .devtools file

The .devtools file was an attempt to solve the Workspace mappings
problem. It didn't really work and didn't get much traction.

Today, it is no longer needed since Persistence2.0 solves the mappings

This patch is a pre-step before enabling Persistence 2.0 experiment
by default.

BUG= 277885 

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


Sign in to add a comment