Live reload server mistakenly sends CSS changes, causing delays

[orf]

When using ember serve with the latest ember-cli and after making a change the livereload seems to cause my browser to make a lot of requests for the same resources before the page is refreshed and the changes are visible:

GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615257 200 1.639 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615256 200 1.812 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615260 200 1.616 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615259 200 1.694 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615263 200 1.568 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615261 200 2.093 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615266 200 1.743 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615265 200 6.908 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615267 200 1.568 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615267 200 2.780 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615269 200 2.715 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615269 200 3.057 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615272 200 1.508 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615271 200 2.044 ms - -
GET /assets/doge-cf3f3ab3139c1a87f4e60379c92b0354.css?livereload=1455795615274 200 2.207 ms - -
GET /assets/vendor-485f7b7543b1533623fce14cbe4309eb.css?livereload=1455795615273 200 2.481 ms 

This isn't exactly a critical issue, but it would be nice if it didn't happen.

[orf]

Hi, I've managed to track down the cause of this. Inside the livereloaders reload function there is this code:

if (options.liveCSS) {
    if (path.match(/\.css$/i)) {
      if (this.reloadStylesheet(path)) {
        return;
      }
    }
  }

This is getting called with every unminified CSS path name. So for example we include a selection of the many highlightjs styles in our ember-cli-build.js:

var HighlightjsAssets = new Funnel(BASE + "highlightjs", {
    include: ["**/*.js", "styles/*.css"],
    destDir: "/assets/highlightjs"
});

But when the project is rebuilt every one of the CSS files are sent as a changed path, which never happened in the previous version as far as I could tell. Those stylesheets are not even loaded on the page, and have not changed at all. This causes Chrome to hang for a while it repeatedly loads the same CSS file, before finally reloading the page.

[rwjblue]

Can you provide a demo repo and steps to reproduce?

[orf]

Done: https://github.com/orf/buggy-ember-cli-app

In this test app it actually only loads a few before cancelling the rest, but on my medium/large app it is a significant slowdown:

Just serve it and make a tiny change to any .js file. Happens on Windows as well I'm told.

[orf]

Hi, were you able to reproduce this? If not I can spend some time looking into why.

[stefanpenner]

my guess is that some input filter isn't caching, and instead constantly provide fresh input files. Causing the live-reload server to believe that all have changed.

[orf]

Could this be to do with the SRI fingerprint?

[stefanpenner]

Yes it could, can you share w small app that demonstrates this problem. Il gladly debug it

[orf]

This one demonstrates the issue: https://github.com/orf/buggy-ember-cli-app

[stefanpenner]

this appears to be bugs in both SRI and broccoli-asset-rev

• should use broccoli-persistent-filter broccoli-asset-rewrite#31
• any-change causes everything to be dirtied jonathanKingston/broccoli-sri-hash#20

[nathanhammond]

This isn't actionable on the Ember CLI side of things and we have tracking issues at the upstream repositories. As such I am closing this issue.