Browser-sync: Source maps not loading in Chrome 43 on Mac

Created on 22 May 2015  路  19Comments  路  Source: BrowserSync/browser-sync

Reproduced in Chrome 43 on OS X 10.10

Sources are simply not visible as if there were no source maps, but they are generated and deployed. Without BrowserSync they work just fine.

The server behind proxy is Tomcat 7.0.55

Here's the gist with all relevant sources:
https://gist.github.com/ZIJ/28e2a05e0b96effd4f24

Most helpful comment

This might be an SSL issue. I was having the following symptoms:

  • Problem is only visible in Chrome
  • Sourcemaps load fine the first time around in Chrome, and a subsequent reload doesn't show sourcemaps anymore regardless of whether one purges / skips the cache
  • Bypassing the browser-sync proxy masks the problem

Generating a self-signed certificate, integrating it into my trusted store (i.e. Keychain Minder on Mac OS X) and configuring browser-sync to use it, solved the issue for me. The latter step is achieved by adding the following to gulpfile.js or wherever it is that you initialize browser-sync:

    browserSync.init(
        [/* your watched files as usual */],
        {
                https: {
                    key: "devsupport/browser-sync.key",
                    cert: "devsupport/browser-sync.crt"
                }
        });

All 19 comments

Thanks for reporting but a small repository (instead of a gist) is more appreciated.

Thank you @shinnn for instant reply! That would take some time to isolate the use case, I'll get back here as soon as we have a self-contained repo.

@shinnn I have just added repo for this issue. Please clone this repo just run npm install and then gulp.

cc @ZIJ

screen shot 2015-05-23 at 18 08 41
screen shot 2015-05-23 at 18 08 30
screen shot 2015-05-23 at 18 14 00

@shinnn is this repo sufficient to spot the problem? If not, we could investigate further.

Cloned the repo and tried it out. The problem there is that the script is collected by the time DevTools is opened. Reloading the page makes source maps load. Adding a named function to the end of the script prevents it from being collected:
function a() {}

@repenaxa Could you please explain more detailed?

@mdreizin @repenaxa It appears that the issue is consistently reproduced with network throttling turned on (3G and lower), reloading the page doesn't help. Does it give any clue on the root cause?

cc @shakyShane

I've also noticed that the sourcemaps are not working in Chome 43 on Windows when using BrowserSync as a proxy. The server behind the proxy is Tomcat 8 and connecting using HTTPS.

I noticed that when I use Fiddler to watch my requests, then the sourcemaps work again.

Thanks @mdreizin - using your repo I was able to narrow this down to a single use-case: proxying your https server.

I changed the gulpfile to proxy your insecure server instead on 8080 and the sourcemaps load as expected.

I currently have no idea why the https proxy fails to load them, but at least we've now narrowed down the scope of the bug. Anyone have ideas on this?

Can confirm on Chrome 46 & 44
Working on Firefox 39 (also, hello devtools levelup!)

I does seem to have something to do with HTTPS.

  • initial page load, inspector shows main.css
  • change scss, BS reloads css, inspector shows main.scss (!!)
  • change scss, BS reloads css, inspector shows main.css?rel=1439434873130

The issue was resolved for me by setting up BrowserSync to use a trusted certificate with the below option. I think it may be an issue with Chrome not trusting the localhost certificate that is shipped with BrowserSync. I didn't try adding that certificate to Chrome's trusted keystore.

https: {
            key: "C:\\certs\\server.key",
            cert: "C:\\certs\\server.cer"
        }

@Kruegs tried the same self-signed key that the server is using... both chrome and firefox gave new certificate warnings, but no change in sourcemaps.
FF works, Chrome just shows the css.

@JacobDorman @Kruegs @shakyShane Any luck since this issue was last discussed?

I'm experiencing the same thing.

  • initial page load

    • Chrome inspector shows app.css (bad)

    • Firefox inspector shows source.scss (good)

  • I'm modifying the scss, BS injects the css again

    • Chrome inspector shows source.scss (good)

    • Firefox inspector shows source.scss (good)

Somehow Chrome is having trouble with initial load of BS. When BS is not involved (when pulling my files from an external web server), sourcemaps are running fine.

I'm also using BS with a proxy on an https server.

Any idea?

Update:

I separated both sourcemaps by changing the gulpfile from

return gulp.src(paths.src + assets.scss + files.scss)
        .pipe(plugins.plumber())
        .pipe(plugins.sourcemaps.init())
        .pipe(plugins.sass(sassOptions))
        .pipe(plugins.if(config.cssConcat.enabled,
            plugins.concat(config.cssConcat.finalName + '.css')))
        .pipe(plugins.autoprefixer())
        .pipe(plugins.size(sizeOptions))
        .pipe(plugins.sourcemaps.write(paths.sourcemaps))
        .pipe(gulp.dest(paths.dist + assets.css))
        .pipe(plugins.minifyCss())
        .pipe(plugins.rename(renameOptions))
        .pipe(plugins.size(sizeOptions))
        .pipe(plugins.sourcemaps.write(paths.sourcemaps))
        .pipe(clip())
        .pipe(gulp.dest(paths.dist + assets.css))
        .pipe(plugins.if(config.browsersync.enabled, browserSync.stream({match: files.css})));

to

var sourceStream = gulp.src(sourceFiles)
        .pipe(plugins.plumber())
        .pipe(plugins.sourcemaps.init())
        .pipe(plugins.if(config.sass.enabled, plugins.sass(sassOptions)))
        .pipe(plugins.if(config.cssConcat.enabled, plugins.concat(config.cssConcat.finalName + '.css')));

    var unmin = sourceStream
        .pipe(plugins.clone())
        .pipe(plugins.autoprefixer())
        .pipe(plugins.size(sizeOptions))
        .pipe(plugins.sourcemaps.write(paths.sourcemaps));

    var min = sourceStream
        .pipe(plugins.clone())
        .pipe(plugins.autoprefixer())
        .pipe(plugins.cssnano())
        .pipe(plugins.rename(renameOptions))
        .pipe(plugins.size(sizeOptions))
        .pipe(plugins.sourcemaps.write(paths.sourcemaps));

    return merge(unmin, min)
        .pipe(clip())
        .pipe(gulp.dest(paths.dist + assets.css))
        .pipe(plugins.if(config.browsersync.enabled, browsersync.stream({match: files.css})));

and the problem is fixed.

Switching to inline sourcemaps resolved the issue for me.

Having the same issue on Chrome v60 on OS X 10.11. Source maps are loaded from time to time using browser-sync proxy. There is no such a problem on a webserver itself and on Firefox. My connection is over SSL. Setting source maps to use sourcesContent doesn't fix the issue.

This might be an SSL issue. I was having the following symptoms:

  • Problem is only visible in Chrome
  • Sourcemaps load fine the first time around in Chrome, and a subsequent reload doesn't show sourcemaps anymore regardless of whether one purges / skips the cache
  • Bypassing the browser-sync proxy masks the problem

Generating a self-signed certificate, integrating it into my trusted store (i.e. Keychain Minder on Mac OS X) and configuring browser-sync to use it, solved the issue for me. The latter step is achieved by adding the following to gulpfile.js or wherever it is that you initialize browser-sync:

    browserSync.init(
        [/* your watched files as usual */],
        {
                https: {
                    key: "devsupport/browser-sync.key",
                    cert: "devsupport/browser-sync.crt"
                }
        });

Can confirm @domq's solution and fantastic solution.

var browserSyncOptions = {
    proxy: "https://local-server.net",
    notify: false,
    https: {
        key: "/usr/local/etc/apache2/2.4/localhost.key.pem",
        cert: "/usr/local/etc/apache2/2.4/localhost.crt.pem"
    }
};

Has solved both the sourcemaps issue and the local ssl issue. Thanks @domq

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pensierinmusica picture pensierinmusica  路  4Comments

ngryman picture ngryman  路  3Comments

ilianaza picture ilianaza  路  4Comments

ericmorand picture ericmorand  路  3Comments

tonyoconnell picture tonyoconnell  路  3Comments