Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Crash In Browser #111

Closed
lystormenvoy opened this issue Apr 21, 2015 · 9 comments
Closed

Crash In Browser #111

lystormenvoy opened this issue Apr 21, 2015 · 9 comments
Labels

Comments

@lystormenvoy
Copy link

FBVLC and WebChimera are create by u, isn't it? We use fbvlc only to play rtsp stream in browser. But sometimes it crash easily. Will WebChimera be more stable?
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?
Forgive my poor English.

@RSATom
Copy link
Owner

RSATom commented Apr 21, 2015

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
Copy link
Author

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
Copy link
Owner

RSATom commented Apr 21, 2015

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
Copy link

jaruba commented Apr 21, 2015

@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
Copy link

jaruba commented Apr 21, 2015

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
Copy link
Author

Thanks for your replies

@RSATom
Copy link
Owner

RSATom commented Apr 26, 2015

@lystormenvoy, can we close this issue?

@RSATom RSATom closed this as completed Apr 28, 2015
@jaruba
Copy link

jaruba commented Apr 28, 2015

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
Copy link
Owner

RSATom commented Apr 28, 2015

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants