Chrome 34 does not reflect CSS changes until cursor hovers over viewport

[jacksleight]

I've only noticed this since updating to Chrome 34 (specifically 34.0.1847.116), so it may be a result of a new behaviour of Chrome

When I make CSS changes the LiveReload plugin detects/fires the onload event (as logged in dev tools), but the page rendering is not updated until the cursor hovers over the viewport. This seems to happen about 90% of the time.

[wingrunr21]

I see this as well. Perhaps #24 is related? cc @andreyvit

[ByScripts]

Same problem here on Chrome 34.

I tried with Chrome 36 Dev-channel, same problem.

[andersaloof]

I'm seing this in 37.0.2002.0 canary also...

[jeffebauer]

Also occurring in Chrome 35.0.1916.114.

[ghost]

Same issue here, very annoying :( Chrome Version 35.0.1916.153 m

[jitendravyas]

Yes I'm also facing this issue on Ubuntu with chrome 36

[theo-bittencourt]

Same problem here... Chrome 37.0.2062.44 beta, OSX Seems it is not a Livereload's issue. I'm facing it using Sublime Web Inspector.

With this issue, Livereload is useless to me. :/

[dy-dx]

I had to do 2 things to get this working.

1. I increased this timeout value to ~50:

https://github.com/guard/guard-livereload/blob/959cbe22cd258460791a7925c95f2069bf5748d4/js/livereload.js#L735

It seems the higher this value is, the more reliably chrome will draw the new styles.

1. I disabled the Privacy Badger chrome extension. Privacy Badger includes its own CSS file, which LiveReload was interacting with:

For whatever reason, my styles get redrawn way more consistently without this other css file on the page.

[andreyvit]

Hey! I cannot reproduce this myself. Does anyone have an idea how to make this bug happen if it does not happen by itself?

[andreyvit]

I could really, really use some help reproducing this, if anyone is up to it.

[wingrunr21]

I haven't tested this on more recent versions of Chrome. The behavior was simply that you made changes on the backend but the changes weren't reflected in Chrome until you hovered the mouse over the viewport.

[mpdude]

Not sure if it is still an issue for me, haven't noticed it for a while.

[jacksleight]

Yeah I've not noticed it recently either, seems it may have been resolved in a recent update.

[ByScripts]

No longer a problem for me either.

[andreyvit]

Thank you, everyone! I really appreciate all the feedback. I guess it was some random Chrome bug that got fixed. Will close the issue for now.

[woerndl]

I have the same issue using Chrome 40.0.2214.115 and LiveReload 2.0.9. Increasing the additionalWaitingTime to 50 as in https://github.com/livereload/livereload-extensions/issues/26#issuecomment-54250594 fixes it for me to.

I use https://github.com/gruntjs/grunt-contrib-watch as the counterpart if that matters.

[hirenumradia]

Hey.

I was facing this issue as well. I am using chrome Version 41.0.2272.74 m and live reload 2.0.9. I followed the steps in #24 and increased the additionalWaitingTime to 50 in my livereload.js file but it still didn't work.

I had to move my mouse cursor over the screen to get it to refresh. I am using livereload bundled with grunt. These are the grunt modules I am running grunt-contrib-uglify ,grunt-contrib-watch and grunt-contrib-compass.

Solution for me: I looked into why setting the delay was working for some people and looked into script blocking or failing stylesheets/scripts on the page. I noticed ?livereloadXXXXXXX was being append to a failing stylesheet. So I thought it might just be that its a bug with it latching onto a script that never loads which makes it hang.

I removed the failing stylesheet and it has resolved the issue. It seems as if its going to need a JS fix of livereload.js.

[timv88]

This is still an issue in Chrome Version 41.0.2272.101 and gulp-livereload 3.8.0. https://github.com/livereload/livereload-extensions/issues/26#issuecomment-54250594 fixed it for me

[jacksleight]

Can confirm I am also seeing this in Chrome (41.0.2272.118) on OS X again.

[andreyvit]

All right, the bug is still there. But can anyone comment on how I can reproduce it? Are you seeing it every time, on every project, even the simplest ones? If not, what do you need to do to get it to appear?

I can, of course, just increase the delay and forget about it, but I'd really like to understand the issue.

[jacksleight]

Unfortunately this really does seem to happen completely randomly for me. I can go days without it happening, then it'll suddenly start doing it. I've found no reliable way to replicate it.

Also it doesn't even happen consistently when it is doing it. I'm working on a project right now, and I would say about 80% of the reloads don't trigger until you hover over, but the other 20% work correctly.

Sorry, I realise that's the most unhelpful response to a bug report possible :-( . Really wish I could spot any consistency, but I can't.

[dy-dx]

@jacksleight Do you have multiple stylesheets on the page? Look in the Sources pane in chrome devtools and see if ?livereload is being appended to the wrong css file when you trigger a css reload.

[jacksleight]

@dy-dx Ah ha! Interesting...

I only have one local stylesheet, but I also have a Google Fonts stylesheet (which returns a successful 200 response). Looks like if I remove Google Fonts the issue goes away completely (based on my 30 seconds of testing), but if Google Fonts is in there the CSS fails to refresh until mouse over (although it does still appear to work occasionally).

Edit: livereload is being appended to both stylesheets.

[txchen]

@dy-dx I am getting the same issue, too. My test page has multiple css, and they all have ?livereload appended. Until mouse hover, it does not refresh.

42.0.2311.90 (64-bit) Chrome Mac

[carlituxman]

me too with Versión 42.0.2311.90 (64-bit)

[andersaloof]

I've recently tried out browsersync on a couple of projects and I'm seeing the same issue there...

[carlituxman]

I've I have opened the inspector it works!!

[okor]

HACK

For Rails, you can do like this:

  <% if Rails.env.development? %>
    <!-- css live reload hack, Chrome requires focus to repaint page -->
    <script type="text/javascript">
      setInterval(function(){
        document.getElementsByTagName('body')[0].focus();
      }, 250);
    </script>
  <% end %>

For whatever reason, Chrome seems to require focus on the viewport before it will repaint. No worries. That hack will fix you right up. You might want to tune the 250 ms timeout to whatever works for you.

[guiambros]

+1 here; exact same problem.

I'm running Chrome 43.0.2357.52 beta (64-bit) on Ubuntu 14.04. It works 70% of the time, but sometimes it would just stop updating (usually after a quick succession of updates), until I move the mouse over the viewport.

It seems that Chrome is being "smart" detecting the multiple updates, and proactively deactivating the refresh, maybe to save resources.

On the DevTools, I can see the "onload!" number increasing every single time I save the file, so clearly LiveReload is detecting the updates (I'm using gulp-livereload to inform LiveReload).

I tried increasing the timeout to 50 on livereload.js per @dy-dx, but no change. Still fails ~30% of the time.

The only thing that worked was to include the setInterval() in the HTML, as described by @okor above. This solved the problem to me. But that's a workaround, and not a real solution. Unless we make the Chrome extension to inject the timer on the page automatically, but that seems a brute force approach.

update: this was a simple page, with a couple of css files and a handful of javascripts. All extensions were disabled to test, except for LiveReload.

[farneman]

As documented by https://github.com/BrowserSync/grunt-browser-sync/issues/53 this is probably an issue with Chrome itself rather than LiveReload. Chrome seems to stop repainting the viewport when it's not in focus after a delay and then doesn't repaint the viewport until the mouse hovers over the viewport again.

[fyodorvi]

Keeping Developer Tools opened seems to be a workaround.

[lmaran]

Keeping Elements tab in Developer Tools opened seems to be a workaround. Thanks @fyodorvi

[whitneyland]

Keeping elements open does not work around the issue here. Maybe because I've detached CDT into a separate window? Hate this bug.

[surjithctly]

Same Issue for me..

Here is how to reproduce :

My System Conf : Dual Monitors

Windows 8.1 => 64 bit Chrome Latest Sublime Text 3

---

1. Install Sublime text addon, chrome extn, livereload.
2. Choose => HTML root folder (css is in subfolder)
3. Edit HTML => appears right away
4. Edit CSS => Only changes on hovering
5. Add CSS path too in Live Reload
6. Try again
7. Worked Fine First Time
8. Then Editing again, no change until hovering.

Attached a GIF for better Understanding..

@fyodorvi Yes.. Keeping Dev Console Open is a workaround. Strange!

[whitneyland]

@surjithctly and others, I've posted quick fix steps here: https://github.com/guard/guard-livereload/issues/123#issuecomment-116178281

[surjithctly]

@WhitneyLand Do you know, editing extension directly in source makes the App corrupted? We need to re-install to repair. Atleast in Windows :)

[whitneyland]

I haven't noticed any problems or warnings on Mac, but surely a proper install would be preferred so thanks for the heads up.

[xmxstudio]

I had the same problem..Version 43.0.2357.130 (64-bit) BUT Only when the dev tools was undocked! re-docking dev tools or turning it off made it work fine

[vrozkovec]

Hi, found a solution that works for me, source: http://stackoverflow.com/a/20982320/3356028

Add to CSS file:

@-webkit-keyframes repaintChrome {from { padding: 0; } to { padding: 0; }} body { -webkit-animation: repaintChrome infinite 1s; }

[mlidbom]

I'm having the same problem. additionalWaitingTime = 50 instead of 5 fixes it for me too as it seems to for most people.

0.04 seconds? Who can even notice that? It's been more than a year without a solution that avoids this 0.04 second delay. Please just change the value to 50 and it will work for just about everyone!

More details:

I'm using gulp-livereload.

Keeping the devtools Elements tab open fixes it for me as well. But only if it is the Elements tab that is active.

vrozkovec's css hack fixes it for me as well. But I really don't want to add strange hacks to the css. I have absolutely no idea what other effects that CSS might have. Also it will not fix it for anyone else....

[andreyvit]

@mlidbom Problem is that 50 doesn't fix the problem for everyone. But perhaps you're right and it's time to add a stupid workaround.

[mlidbom]

I probably overused the bold + exclamation point combination. Sorry about that :) Frustration does that to me sometimes.

But yes, that was what I was trying to suggest. I'm not saying that it is perfect, but it has a minimal negative impact, while apparently fixing it for most people. Seems like a reasonable thing to do until a better solution can be found.

Also, the 5 in there at the moment seems like exactly the same kind of strange workaround/hack to me. This will just change an already present magical delay to one that is slightly longer....

[byNiko]

Running into the same problem. When I have the developer window (f12 win 8.1) open - livereload works as expected When I close the developer window I have to hover over the window. Chrome Version 45.0.2454.85 m

[e2]

@mlidbom, @andreyvit :

FWIW I've made it so additionalWaitingTime can be easily set from the Guardfile: https://github.com/guard/guard-livereload/pull/147

Also, you can use ERB to adapt any hardcoded setting in the livereload.js - so other workarounds can be easily added and switched on/off from the Guardfile.

(Since it's Ruby, you can load these settings from wherever you want, even a config file in your home dir).

I don't like workarounds, but: "well-documented/supported workaround" is better than "no workaround".

Feedback is welcome.

[EmmanuelOga]

Hack time, in case it helps someone (on linux).

Because of [reasons] I need to use an old version of Chrome (39 @ linux).

I think the screen not repainting has been fixed in later versions of Chrome, but if you are stuck with an old Chrome, this can help...

You'll need xdotool. Have your watcher run this on file change:

xdotool search --name "Your Window Title - Chromium" windowactivate

The name of the browser window can be find with xprop.

This could disrupt your flow though, depending on how your window manager reacts to this. Emphasis on the hack word :-).

[davestewart]

What can't additionalWaitingTime be passed to live reload as a configuration value?

[e2]

@davestewart - it can (since version 2.5.0).

See the "additional options" here: https://github.com/guard/guard-livereload#options

[davestewart]

Thanks. Not sure i understand though - do I have to install ruby libraries to get node libraries to work?

[e2]

@davestewart - sorry, wrong project. This solution is for guard-livereload only. For the extensions there probably has to be a protocol change to support such settings.

[dmitry]

What is actually an issue here TL;DR?