5 ms·

Not sure linking to the FTP mirror is all that useful. Here are the release notes: https://www.mozilla.org/en-US/firefox/22.0/releasenotes/ https://www.mozilla.

Not sure linking to the FTP mirror is all that useful. Here are the release notes: https://www.mozilla.org/en-US/firefox/22.0/releasenotes/ https://www.mozilla.org/en-US/firefox/22.0/releasenotes/ Highlights: WebRTC, asm.js, flexbox, and web notifications are present and enabled by default.

masklinn 13y ago
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.
- giorgosts 13y ago
  So can a website read a users clipboard, and if yes, how can we disable this "feature"?
  - mh- 13y ago
    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/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/CopyAndPaste.html http://developer.apple.com/library/mac/documentation/AppleAp... [2] http://www.w3.org/TR/clipboard-apis/ http://www.w3.org/TR/clipboard-apis/
    - giorgosts 13y ago
      Thanks, it's just brought back memories of IE6 where a website could arbitrarily read user clipboard without notice
      - oneeyedpigeon 13y ago
        What?! Are all those companies still using IE6 (and, consequently, holding back progress for the rest of us) aware of this massive security hole?
        vidarh 13y ago
        Hey, it's a feature. We can "fund" the time spent on IE6 workarounds by selling data obtained from paste buffers.
        jonknee 13y ago
        Companies using IE 6 have many more security problems than clipboard access.
        Drakim 13y ago
        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.
  - masklinn 13y ago
    > 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-part-data 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.
    - aaronm67 13y ago
      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.
      - masklinn 13y ago
        It might be restricted to focusable/editable components, e.g. a `contenteditable` block should work.
        aaronm67 13y ago
        Yep, you're correct http://jsbin.com/odupog/1/edit 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.
- deleted 13y ago
  [deleted]
joelthelion 13y ago
Are there any good web applications based on WebRTC yet?
- shacharz 13y ago
  Tell me what you think of this one: http://www.sharefest.me/ http://www.sharefest.me/
- mwarkentin 13y ago
  Group video chat: https://talky.io/ https://talky.io/
  - shacharz 13y ago
    I absolutely love your UI, and the game idea while waiting.
- changdizzle 13y ago
  or build your own! www.tokbox.com disclaimer: BD @ tokbox
- willaaye 13y ago
  Check out LiveNinja http://www.liveninja.com http://www.liveninja.com which is based on WebRTC for the video calls
numbnuts 13y ago
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/Releases/22 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
- blueveek 13y ago
  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/linux/devtools/netmonitor.css#l474 http://dxr.mozilla.org/mozilla-central/source/browser/themes...
_greim_ 13y ago
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?
- masklinn 13y ago
  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/ http://css-tricks.com/old-flexbox-and-new-flexbox/
  - bzbarsky 13y ago
    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.
    - masklinn 13y ago
      > 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/ http://www.the-haystack.com/2010/01/23/css3-flexbox-part-1/ [1] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-box-flex https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-box-fl...
      - bzbarsky 13y ago
        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.

masklinn 13y ago

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.

giorgosts 13y ago
So can a website read a users clipboard, and if yes, how can we disable this "feature"?
- mh- 13y ago
  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/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/CopyAndPaste.html http://developer.apple.com/library/mac/documentation/AppleAp... [2] http://www.w3.org/TR/clipboard-apis/ http://www.w3.org/TR/clipboard-apis/
  - giorgosts 13y ago
    Thanks, it's just brought back memories of IE6 where a website could arbitrarily read user clipboard without notice
    - oneeyedpigeon 13y ago
      What?! Are all those companies still using IE6 (and, consequently, holding back progress for the rest of us) aware of this massive security hole?
      - vidarh 13y ago
        Hey, it's a feature. We can "fund" the time spent on IE6 workarounds by selling data obtained from paste buffers.
      - jonknee 13y ago
        Companies using IE 6 have many more security problems than clipboard access.
      - Drakim 13y ago
        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.
- masklinn 13y ago
  > 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-part-data 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.
  - aaronm67 13y ago
    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.
    - masklinn 13y ago
      It might be restricted to focusable/editable components, e.g. a `contenteditable` block should work.
      - aaronm67 13y ago
        Yep, you're correct http://jsbin.com/odupog/1/edit 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.
deleted 13y ago
[deleted]

joelthelion 13y ago

Are there any good web applications based on WebRTC yet?

shacharz 13y ago
Tell me what you think of this one: http://www.sharefest.me/ http://www.sharefest.me/
mwarkentin 13y ago
Group video chat: https://talky.io/ https://talky.io/
- shacharz 13y ago
  I absolutely love your UI, and the game idea while waiting.
changdizzle 13y ago
or build your own! www.tokbox.com disclaimer: BD @ tokbox
willaaye 13y ago
Check out LiveNinja http://www.liveninja.com http://www.liveninja.com which is based on WebRTC for the video calls

numbnuts 13y ago

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/Releases/22 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

blueveek 13y ago
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/linux/devtools/netmonitor.css#l474 http://dxr.mozilla.org/mozilla-central/source/browser/themes...

_greim_ 13y ago

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?

masklinn 13y ago
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/ http://css-tricks.com/old-flexbox-and-new-flexbox/
- bzbarsky 13y ago
  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.
  - masklinn 13y ago
    > 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/ http://www.the-haystack.com/2010/01/23/css3-flexbox-part-1/ [1] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-box-flex https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-box-fl...
    - bzbarsky 13y ago
      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.