Crash In Browser

[lystormenvoy]

Crash In Browser

[RSATom]

FBVLC and WebChimera are create by u, isn't it?

Yes, it is

We use fbvlc only to play rtsp stream in browser. But sometimes it crash easily. Will WebChimera be more stable?

You are the first who complain FBVLC stability for about a year since last version was released. I can't promise there are no bugs in WebChimera, but it's pretty stable I think. Anyway, if you will find some bug - it will be fixed (if you will report it of course)

By the way, if we don't use fbvlc and use official VLC instead, it is stable but we can't promise all browser can't load the plugin. Do you know why?

Better ask guys from videolan about it. I didn't touch Vlc Web Pugins from around 2012 (when I started FBVLC).

Forgive my poor English.

My English is far from perfect too :)

[lystormenvoy]

About the stability of fbvlc, I mean sometimes the Browser(I usually use Chrome) tells me that, the page lose response :'the page title'. Of course in Chinese. Usually appear when I switch the tab.

[RSATom]

Never met something like this, anyway I don't plan any updates for FBVLC. If you need something similar you could use original Vlc Web Plugins or WebChimera (maybe in FBVLC mode)

[jaruba]

@lystormenvoy I don't even think that the issue you are describing is a problem of FBVLC, it is most likely a problem with your javascript.

JS mostly uses one timeline thread.. This means that when you use a function that gives a return [value-here] at the end, then the entire browser will freeze until that return value is received.

This happens because the browser is stuck in the main timeline thread until it receives that response.

I don't think an NPAPI Browser Plugin could ever freeze the browser, only JS can freeze it. You could put some console.log("you are here #") after each line of your JS code and after a freeze check the Developer Console to see which line was freezing the browser, then instantiate that line with setTimeout(function() { myfunction(); },1).

The cool thing about setTimeout() is that it creates a different timeline thread, so the browser won't freeze waiting for a response, it will only freeze if the main timeline thread is in waiting mode.

A second reason could be that you are using a very long loop in javascript. while and for loops do the same thing to the main timeline thread, it freezes it in waiting mode until they have ended. This is also fixed with setTimeout().

To better understand the difference between synchronous and asynchronous functions, please refer to this stackoverflow question (the question is for node.js but the answers apply to all JS)

[jaruba]

As you mentioned this usually happens when you change tabs, it could also be that you are watching a high resolution video and you do not have a very good computer. FBVLC in windowless mode is known to use a lot of resources and not perform very well with high resolution videos while the browser always uses more resources when changing tabs.

Or it could be some other browser plugin from chrome, other plugins are known to make changes to your pages and react to browser actions, so you could also try to disable all chrome plugins to see if a different plugin is causing this behavior.

[lystormenvoy]

Thanks for your replies

[RSATom]

@lystormenvoy, can we close this issue?

[jaruba]

A small update on this, I found this in the chrome comic book:

http://www.google.com/googlebooks/chrome/small_30.html

Page 31 seems to explain how NPAPI's are handled by the chrome browser and from what I understand from that page, as I stated above, NPAPI's can never freeze chrome, because they are a separate process.

So this was definitely a problem with the JS or lack of computer memory.

[RSATom]

Yes, it's correct. All modern browsers runs NPAPI plugins in separate process.