Don't forget ES6 fat arrows! That and right-dockable dev tools excites me more than they probably should.

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

The devtools are indeed dockable on the right now in FF 22, but not responsive yet (so when little horizontal real estate is available, the tools will look and feel very cramped).

The upcoming versions address this issue (in the end, it's all just CSS; for example: [0]).

[0] http://dxr.mozilla.org/mozilla-central/source/browser/themes...

Also, clipboard data access. With Opera's switch to chromium, Firefox was the last browser without programmatic access to the clipboard[0] (though as usual MSIE has a non-standard implementation) so you had to listen for the paste event and post-process whatever garbage had been dumped in your paste area (and of course couldn't access high-level media types)

[0] Opera, as far as I remember, has neither clipboard access nor a "paste" event, the POS.

So can a website read a users clipboard, and if yes, how can we disable this "feature"?

> So can a website read a users clipboard

Yes and no, the website can access clipboard data specifically when you're pasting as a user-triggered operation (C-v/M-v or "Paste" from a contextual menu) (that is the clipboard data is only accessible from the `paste` event).

This allows an application to access alternative representations (the clipboard can store multiple representations of the same data e.g. text and html and image and whatever, and the application can then pick the most appropriate — or all of them) and to pre-process clipboard data before inserting it programmatically. Very useful with e.g. RTE. Arbitrary clipboard access most definitely isn't allowed.

See http://www.w3.org/TR/clipboard-apis/#pasting-html-and-multi-... for security and privacy considerations.

> if yes, how can we disable this "feature"?

In firefox, probably by going to about:config and setting `dom.event.clipboardevents.enabled` to `false`. In webkit and MSIE (which have had the feature for ages) I have no idea.

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.

No, not unless you initiate a paste operation manually (literally, as in by hitting ctrl-v or etc.)

This is one of the ways that pasting images from your clipboard into, say, an image hosting site can work.

I had a difficult time finding fuller explanations of the capabilities - mostly because there isn't a standard API across browsers yet - but here[1] are the relevant Safari docs.

There's also a working draft[2] from the W3C for a standardized API.

[1] http://developer.apple.com/library/mac/documentation/AppleAp...

[2] http://www.w3.org/TR/clipboard-apis/

Thanks, it's just brought back memories of IE6 where a website could arbitrarily read user clipboard without notice

What?! Are all those companies still using IE6 (and, consequently, holding back progress for the rest of us) aware of this massive security hole?

Hey, it's a feature. We can "fund" the time spent on IE6 workarounds by selling data obtained from paste buffers.

Companies using IE 6 have many more security problems than clipboard access.

At this point of time IE6 is a wide open door, something as trivial as reading your paste isn't that big of a deal in comparison.

Are there any good web applications based on WebRTC yet?

Tell me what you think of this one: http://www.sharefest.me/

Check out LiveNinja http://www.liveninja.com which is based on WebRTC for the video calls

Group video chat: https://talky.io/

I absolutely love your UI, and the game idea while waiting.

or build your own!

www.tokbox.com

disclaimer: BD @ tokbox

Oh weird. I remember trying out FlexBox three years ago and having it work in FF. Does this just mean they dropped the -moz- prefix requirement?

It's a bit more complex: there are actually 2 flexbox specs with different syntaxes, one from 2009 (now deprecated) and one from 2011[0]. Firefox has supported the old syntax circa Firefox 2 (Safari from 3.1, Chrome from the first version).

This is about the new syntax and current CR.

[0] http://css-tricks.com/old-flexbox-and-new-flexbox/

Firefox never supported the old flexbox. It has XUL boxes (dating back to 1998 or so), which the old flexbox was syntactically, and somewhat behaviorally based on. But they predate those drafts by 10 years.

> Firefox never supported the old flexbox.

I'm not sure why you're asserting that when you're completely wrong. Not only did Firefox support the old flexbox, it still does as of Firefox 22: [0] still works and uses the old (and prefixed) flexbox syntax, and said old (and prefixed) syntax remains documented on MDN with a note that it's deprecated[1]

[0] http://www.the-haystack.com/2010/01/23/css3-flexbox-part-1/

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-box-fl...

My point is that the syntax in question is used for XUL boxes, and has been for going on 15 years. It's not used for any sort of implementation of the old flexbox draft.

The old flexbox draft is similar to XUL boxes in some ways, and quite different in other ways. Trying to use XUL boxes and expecting the old-flexbox behavior as a result will land you in trouble, as happens with depressing regularity when people use "display: -moz-box".

The MDN documentation is sadly wrong, because it ignores the fact that the properties _look_ similar but have totally different behavior. Thank you for pointing that out; I'll make sure it gets fixed.

Note to self: never engage in a public argument about Firefox internals with bzbarsky.