hexo-browsersync Problem with long pages

I just install hexo and try to use hexo-browsersync. But I notice a bug: when generated page size bigger than some number (~1000 words) it can't be fully loaded, in chrome source code it looks like this:

screen shot 2017-01-20 at 19 05 19

If there is not so much characters in a page, everything is ok. So it happens only in big posts. When I uninstall hexo-browsersync bug is disappear, so it's definitely problem with hexo-browsersync.

I suppose it's could be some stream or buffer limit, but I'm new to node and can't solve this...

Jan 20 '17 17:01 PazzaVlad

I meet the same problem. And it seems that this problem is related to theme, I'm trying to find the answer...

Apr 30 '17 17:04 giuem

+1 Meet the same problem. Seems like a problem caused by the buffer size.

May 05 '17 02:05 xsfishxs

Is this still a problem? We recently updated the module too.

Dec 05 '17 11:12 tcrowe

@tcrowe Problem still remains. Can you reproduce this bug?

Dec 05 '17 16:12 giuem

I don't know if this is the same bug but I did get a very weird problem with a large post.

As you can see in the image it had intermittent blank spots. There was no error from hexo or the browser when this happened.

This is how I tried to reproduce your bug:

# create the project
mkdir hexo-bsync-big-text
cd hexo-bsync-big-text
hexo init

# generate some random text for the posts
# the issue reports anything around 1000 words
npm install chance-cli -g
hexo new post "one"
hexo new post "two"
hexo new post "three"

paragraph_count=100

for (( i = 0; i < $paragraph_count; i++ )); do
  chance paragraph >> source/_posts/one.md
  echo '\n\n' >> source/_posts/one.md
done

for (( i = 0; i < $paragraph_count; i++ )); do
  chance paragraph >> source/_posts/two.md
  echo '\n\n' >> source/_posts/two.md
done

for (( i = 0; i < $paragraph_count; i++ )); do
  chance paragraph >> source/_posts/three.md
  echo '\n\n' >> source/_posts/three.md
done

npm install
npm install hexo-browsersync --save
# it installed [email protected]

hexo serve --debug

On a hunch I tried commenting out the Stylus code and the page started to render all the text again. I'm using landscape theme in my demo.

Which theme are you using @giuem ?

Dec 05 '17 16:12 tcrowe

I'm using this theme. And I have try your demo with this theme, the bug doesn't reproduce. Maybe this bug is related to post content?

The bug looks like this, html code was cut off. snipaste_2017-12-06_12-15-41

snipaste_2017-12-06_12-17-46

Dec 06 '17 04:12 giuem

I tried it again with your theme (very nice!) but I did not reproduce the error.

If you would please try a few things:

Somewhere around here: https://github.com/hexojs/hexo-browsersync/blob/master/lib/browsersync.js#L31

Add:

console.log('op', op)
console.log('pos', pos)
console.log('snippet', snippet)

Lets see what the output is.

Another thing you can try is upgrade all modules:

# upgrade hexo and get module updater
npm install npm-check-updates hexo@latest -g

# in your project, updates versions
ncu -an 
npm install

# clean
rm db.json debug.log

hexo serve --debug

You can also tell us npm ls --depth=0 which can show us other plugins that may modify source

Thank you!

Dec 06 '17 21:12 tcrowe

I am having the same issue with this theme (although slightly modified): typing. I don't think it has to deal with the theme itself. The only thing I see in the console is this:

WebSocket connection to 'ws://localhost:3000/browser-sync/socket.io/?EIO=3&transport=websocket&sid=GGauSBElfMuLBbrVAAAE' failed: WebSocket is closed due to suspension.

I assume this could be well the reason for dropping rendering at an almost random point.

Feb 16 '18 11:02 arsenicoco

The same problem, may be the error is here. sometimes the pos of </body> may has wrong value.

Apr 10 '18 13:04 kyya

Do you know how to get a failing test case for this, @Anapopo ? We could not reproduce the error.

Apr 11 '18 21:04 tcrowe

pos 138 
op <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Error</title> </head> <body> <pre>Cannot GET /es6-promise.map</pre> </body> </html> 
snippet <script id="__bs_script__">//<![CDATA[ document.write("<script async src='http://HOST:3000/browser-sync/browser-sync-client.js?v=2.24.6'><\/script>".replace("HOST", location.hostname)); //]]></script>

it's very strange, every time the log shows a error repsonse, but the browser show the page ok

Jul 29 '18 10:07 fatfatson

  function converter(content, req, res, callback) {
    var op = content.toString('utf8');
    var pos = op.lastIndexOf('</body>');

    //console.log('op', op)
    console.log('op last', op.substring(op.length-3000))
    console.log('op length', op.length)
    console.log('pos', pos, )
    return callback(null,op);

    if (!~pos) {
      return callback(null, content);
    }

    // op = op.substring(0, pos) + snippet + op.substring(pos);
    callback(null, op);
  }

i don't know why here the op is already truncated, even the plugin does nothing, the result is wrong. but if commenting the the app.use(...), then result is correct...

Jul 29 '18 13:07 fatfatson

OK, I think I have found the problem! it's in connect-injector:

      write: function (chunk, encoding) {
        if (this._interceptCheck()) {
          if(!this._interceptBuffer) {
            debug('initializing _interceptBuffer');
            this._interceptBuffer = new WritableStream();
          }

            debug('write', new Buffer(chunk,encoding).length);
            return this._interceptBuffer.write(new Buffer(chunk,encoding));
          //return this._interceptBuffer.write(chunk, encoding);
        }

it redirects res.write to its own WritableStream, but fails to provide a suitable encoding, (here is undeinfed, but it should be utf8), so data with none-ascii would be lost. replace the write with Buffer solves it.

Jul 29 '18 14:07 fatfatson

@fatfatson 🤔

That's interesting you may have found a solution after all this time. We could not reproduce it. Were you able to? If so, how?

Jul 29 '18 21:07 tcrowe

@tcrowe making a long post( >130K in my case) with chinese would reproduce it

Jul 29 '18 22:07 fatfatson

@tcrowe

@fatfatson is right. This problem has been reproduced with hexo-browsersync:0.3.0. Have you ever tested with CJK(Chinese/Japanese/Korean) strings?

How to reproduce

Install browser-sync:0.3.0
Copy japanese lolem ipsum from here
Create test.md and paste lolem ipsum 10 times. It should be over 13000 characters.
hexo serve and go to /test.html

What happens?

Hexo will not render the whole contents.
- Only 8000 characters were rendered in my environment.
- The partial of footer (if you devide it) will not be rendered.