There was a pretty interesting talk about using differences in style render time to get history.

https://www.youtube.com/watch?v=KcOQfYlyIqw

It's pretty interesting, and can be done in a way that doesn't require any user input.

We did get libav working, but it was much less stable than FFmpeg, and we couldn't get swscaler working (which meant a lot of videos would not work)

There shouldn't be that much difference between the two forks. Which parts were failing?

For swscale, was it compile problems or something later?

Also, if you have a way to run libav's "make fate" (regression tests), do you know which ones fail?

I'm not sure if we can private message on here, but if you would email me at aaronm67@gmail.com, or contact us on the github project, I can let you know our progress and where we got caught up.

In our testing, in the latest version of Chrome, there is about a 75-80% performance hit. So a 6-hour native encoding would take a little over a day to compile (we're working on getting more accurate benchmarks)

You're right, you're not going to use this to encode movies or very large media files, but for encoding shorter clips, the performance isn't unreasonable.

I don't actually think file size to download is much of an issue - the current build is a little over 6mb gzipped, which isn't much bigger than most Youtube videos.

For building a "stripped down" version, there is a config flag "--disable-everything" that can be used, and I will investigate it a little more. We probably won't end up hosting the compiled file, just out of the interest of repo-size, but I can certainly build a "build-minimal" script.

In Underscore, you can do something like:

    _([ ... ]).map( ... ).filter( ... ).value()

It's not exactly extending the native array...but there are far fewer side effects to doing it this way.

The problem with this is that it's doing multiple iterations. LINQ on the other hand builds up an expression tree that is "compiled" into a single loop when `ToList()` (or some other method which gets the results) is eventually called.

I've been an Opera user for a long time, mostly because opening new tabs always felt very fast, much faster than Chrome or Firefox, and because keyboard/mouse shortcuts were so configurable.

They've made tabs slower to open and have gotten rid of configurable keyboard/mouse shortcuts -- it's now just Chrome with a different skin.

In Firefox, it seems like you can only catch Clipboarddata on input boxes still

    document.body.addEventListener("paste", function(e){
        console.log("paste event fired") 
    })

In Chrome, this will fire when you paste, in Firefox it will not.

It might be restricted to focusable/editable components, e.g. a `contenteditable` block should work.

Yep, you're correct

http://jsbin.com/odupog/1/edit

Either way, should alleviate some of the privacy concerns, as you can only get ClipboardData from elements where "paste" has a visible effect.