User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Steps to reproduce: 1. Copy some data from an application that adds RTF data to the clipboard. On Mac, TextEdit.app is fine for this (just make sure it's in rich text mode, not plain text mode). On Windows, I believe MS Word may work for this, but the user who reported this to us was using NagarSoft PhraseExpander, so this is what I verified it with there. 2. Create a new document with a contenteditable section, and add a "paste" event handler. 3. Paste your rich text copied in step (1). Actual results: In the event handler, event.clipboardData.types only includes "text/plain". Expected results: In the event handler, event.clipboardData.types should also includes "text/rtf", and possibly "text/html". If you allow Firefox to handle the paste itself, it will automatically convert the rich text data to HTML and insert that. At the moment, if you want to handle the data yourself (by calling event.preventDefault() and then using clipboardData.getData( type )) you can only access the plain text. Worse, there is no indication that there is anything other than the plain text, so I cannot let it fallback to the dreadful hack of creating a dummy area and letting the browser paste into there, then inspecting the contents to see what it did. Chrome lists both "text/rtf" and "text/html" in the types (and lets you get the HTML conversion). Safari lists "text/rtf" but does not list "text/html" (and does not let you get the HTML conversion). This still allows you to know to fallback to the old **** method, while handling other pastes with more control.

Updated to FF45, it's fixed.

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598