Webtorrent 2 working in Chrome

[emersion]

• Fix Chrome and Opera Memory related errors
• Check for support before using StreamSaver.js and fallback to WebTorrent.

if ( WebTorrent && Firefox ) {
    WebTorrent;             // Firefox only, for now.
} else if ( WebTorrent && StreamSaver && overHTTPS ) {
    WebTorrent+StreamSaver; // Chrome &  Opera.
} else {
    http;                   // Midori, Epiphany, IE.
}

[btkostner]

You will want to add streamSaver to the blacklist for JS linting, or add a .min.js ext to it.

[lewisgoddard]

I don't see this working as intended in Chrome, WebTorrent continues as before, but steamSaver seems to try and load from a pop-up which gets blocked.

1. Make sure in your settings there is no exception to allow pop-ups.
2. Attempt to download as normal.
3. streamSaver is blocked from loading.

• Chrome (70%) - Pop-up blocked, if I allow it then it works with a brief glimmer.
• Firefox (20%) - Seems to fallback to pure WebTorrent correctly.
• Opera - As Chrome.
• Epiphany (Loki) - Falls back to direct links nicely.
• Midori (Freya) - Untested (presumably falls back like Epiphany).

[lewisgoddard]

So jimmywarting/StreamSaver.js says (emphasis added):

So the one and only other solution is to do what the server does: Send a stream with Content-Disposition header to tell the browser to save the file. But we don't have a server! So the only solution is to create a service worker that can intercept links and use respondWith() This will scream high restriction just by mentioning service worker. It's such a powerful tool that it need to run on https but there is a workaround for http sites: popups + 3rd party https site. Who would have guess that? But I won't go into details on how that works. (The idea is to use a middle man to send a dataChannel from http to a serviceWorker that runs on https).

So it all boils down to using serviceWorker, MessageChannel, postMessage, fetch, respondWith, iframes, popups (for http -> https -> serviceWorker), Response and also WritableStream for convenience and backpressure

This leads me to believe that this might work in Chrome and Opera over HTTPS. I have asked @btkostner to deploy a test so we can see more easily without everyone needing to set one up.

[btkostner]

It seems to be angry at cross domain for the beta site: http://beta.elementary.io/branch/origin/webtorrent/

[emersion]

What about the HTTPS version? https://beta.elementary.io/branch/origin/webtorrent/

[lewisgoddard]

Actually, you need to set a release_filename in the php config file (64-bit please).

[btkostner]

added, but the script expects a file ending in .torrent which we don't have. It should end with .iso

Filename: elementaryos-0.3.2-stable-amd64.20151209.iso

[lewisgoddard]

That script isn't adding the file, it's adding the torrent file, which is only on the ams3 downloads host.

[btkostner]

I guess that would be why I can't access it then :P

[lewisgoddard]

Looks like this does work fine over HTTPS, but not HTTP with StreamSaver. We just need to add this check and it can all be moved to webtorrent-2 for merging after loki

[lewisgoddard]

The only thing I'd want is streamSaver ming to JSDelivr, but that can be done in webtorrent-2

[jimmywarting]

Yea, popups... my most hated thing
But that was the only way i was able to install a service worker. The top domain needs to be https... It wasn't enough to have a iframe that was in https

either way... The reason why a popup can be blocked is if it's not open durning a user interaction event... onclick will open the popup just fine.

but doing onclick = setTimeout(open('url'), 5000) will block the popup since it wasn't open durning a user interaction event

But it don't seems like a problem to you if your production site is using https

btw my next big release will reduce the nr of popups a site needs to open since it will use the same channel when it has been establish with the SW (it also removes the iframe when it has been establish, seems pointless but the iframe is not needed anymore)
So when you create a writableStream when you get the torrent metadata then the user interaction is already to late and will cause the popup to be blocked
This gave me an idea to make the "setupChannel" function publicly available so you can do something like

onclick = evt => {
  streamSaver.setupChannel() // open the popup send a messageChannel to SW then close the popup
  // then later you can call createWriteStream without seeing any more popups
  setTimeout(()=>{ // or onTorrent event
    streamSaver.createWriteStream(...) 
  }, 5000)
}

Otherwise you need to do something like

stream = streamSaver.createWriteStream('unknown filename')
onTorrent(torrent){
  stream.write(...)
}

Thanks for giving me this idea about making setupChannel available ;)