Summary: Removing the concept of "isWindows", as that seemed to land Linux into a forgotten bucket.  IMO the shortcuts should simply be split between Mac and PC.

Reviewed By: sophiebits

Differential Revision: D6777189

fbshipit-source-id: 9c596c4c544298f0ac46470988ed2992698e0dca

…itor.react` to make it possible to produce editor commands from these keys

Summary:
Previously, it was impossible to do this:

```
function mapKeysToEditorCommands(e) {
  if (mentionsAutocompleteIsOpen) {
    switch (e.keyCode) {
      case Keys.UP:
        return 'MentionsAutocomplete/select-previous';
      case Keys.DOWN:
        return 'MentionsAutocomplete/select-next';
    }
  }
  return getDefaultKeyBinding(e);
}

<DraftEditor
  keyBindingFn={mapKeysToEditorCommands}
  ...
/>
```

…because we didn't give TAB, ESCAPE, LEFT, UP, RIGHT, or DOWN a chance to produce a command name.

This pull request:

1. deprecates the prop-based key handlers (`onUpArrow` et al.) and encourages people to move their custom key logic into a `keyBindingFn`, and
2. lets the named keypresses fall through to the `keyBindingFn` whenever a prop-based key handler isn't supplied.
3. Updates the homepage and the rich text example.

![tabs](user-images.githubusercontent.com/13243/35651838-f129bf4a-0695-11e8-971b-38dbae48fd23.gif)
Closes #1637

Differential Revision: D6864155

fbshipit-source-id: 23efb4caac25b1bc867350a1212f142b5b3ce7ab

…lock

Summary: In some cases, it's valuable to expose the current position of a decorated component within its content block for styling purposes. (Example: Apply certain styling to a decorated component if a certain entitiy is directly next to that component).

Reviewed By: flarnie

Differential Revision: D6712533

fbshipit-source-id: ea25ae65fafba5283a344a091ac2346fcd4e9bb3

Summary:
**tldr;** Handlers can get called after cWU and before cDU, and they use the
cached 'latestEditorState'. For them to get the fresh version of the state,
we need to update 'latestEditorState' in 'render' because that happens before
the handlers get called.

**The whole story;**
We are trying to remove cWU from `DraftEditor.react.js`. One thing which
currently happens there is that `latestEditorState` gets set to the
nextProps.editorState, so whatever is passed in by the parent. For more context
on the initial attempt at changing this, see
our.intern.facebook.com/intern/diff/D6873303

This change introduced one bug that manifested in various ways - see T26034821
and T26020049. I'll focus on T26020049, which broke
`<AdsBulkTokenizedTextInputWithFieldsSelector>`.

`<AdsBulkTok...FieldsSelection>` has a button for adding a new token, and when
you hit that button it passes `<DraftEditor>` an updated editorState as a prop.
This triggers render #1, and during that render we update the browser
selection, which triggers `focus` and `blur` events. These each trigger another
render of `<DraftEditor>`; renders #2 and #3. Here is how it looks on a
timeline:
```
render #1
+
|
| cWU -> latestEditorState = FRESH_STATE
|
| render -> this.props.editorState = FRESH_STATE
| +
| |
| +--> triggers 'focus' event, calling 'handleFocus' with latestEditorState
|                   +
|                   |
+>cDU fires         | the 'handleFocus' call schedules render #2
                    | with latestEditorState, which is FRESH_STATE
                    |
render #2  <--------+
+
|
| cWU -> latestEditorState = FRESH_STATE
|
| render -> this.props.editorState = FRESH_STATE
|
+>cDU fires
```
When we move the update of latestEditorState to cDM, things go awry like this;
```
render #1
+
|
| cWU -> Nothing ... latestEditorState = STALE_STATE :(
|
| render -> this.props.editorState = FRESH_STATE
| +
| |
| +--> triggers 'focus' event, calling 'handleFocus' with latestEditorState
|                                                +
|                                                |
+>cDU -> latestEditorState = FRESH_STATE         | the 'handleFocus' call schedules render #2
                                                 | with latestEditorState, which is STALE_STATE :(
                                                 |
render #2 <--------------------------------------+
+
|
| cWU -> nothing updates
|
| render -> this.props.editorState = STALE_STATE :(  because this was passed in above
|
+>cDU fires and resets latestEditorState = STALE_STATE :(
```

So we can fix things by updating latestEditorState inside the `render` method,
like so;
```
render #1
+
|
| cWU -> Nothing ... latestEditorState = STALE_STATE :(
|
| render -> this.props.editorState = FRESH_STATE
| +         *and* set latestEditorState = FRESH_STATE
  |
| |
| +--> triggers 'focus' event, calling 'handleFocus' with latestEditorState
|                                                +
|                                                |
+>cDU -> latestEditorState = FRESH_STATE         | the 'handleFocus' call schedules render #2
                                                 | with latestEditorState, which is FRESH_STATE
                                                 |
render #2 <--------------------------------------+
+
|
| cWU -> nothing updates
|
| render -> this.props.editorState = FRESH_STATE which was passed in above
|
+>cDU fires and resets latestEditorState = FRESH_STATE
```

One possible issue would be if `render` fired and then was never completed, in
async. mode, but since Draft is intended to always be run in sync. mode I'm not
worried about that.

Reviewed By: mitermayer

Differential Revision: D6994261

fbshipit-source-id: 80986b853a57f64aa5aafbe667b4d94171d5271c

Summary: Follow-up to D6994261. I believe this is more correct even though it is kind of a hacky approach.

Reviewed By: flarnie

Differential Revision: D7014753

fbshipit-source-id: 6107352ddbe5a90fa3235aae513a3c5b17574c55

Summary:
**Summary**

This PR ensures that the selection is always collapsed for the cases where a user replaces the current selection with matching text.

I admittedly didn't really dig into the original issue when fixing the previous crash :)

**Test Plan**

Small repro:

1. Type in "abc"
1. Select "c" from right-to-left
1. Type "c"
1. Select "c" from left-to-right
1. Type "c"

Thanks to JLarky for bringing this to my intention!
Closes #1661

Differential Revision: D7055502

fbshipit-source-id: ee4cf80d292ee715e40c017e4c6bd18f806b0e24

Summary:
This is closer to how most editors work.
Closes #1659

Reviewed By: sophiebits

Differential Revision: D7073440

Pulled By: sophiebits

fbshipit-source-id: 3f6ab214282878dd7dccf7709fc261ffe350f485

Summary:
**Summary**

Solves #270. Removes restriction on indenting beyond one level deeper than the block above. Also allows indenting the very first item in a list. And all I had to do was delete code!

![image](cloud.githubusercontent.com/assets/253298/19991316/8dfb376e-a1f1-11e6-8e93-b8b49c30010b.png)

**Test Plan**

1. Try indenting the first item in a list.
2. Try indenting a list item more than one level deeper than the item above it.
Closes #762

Differential Revision: D7137964

fbshipit-source-id: 597732b363537e34a0f466c3188f334b3fa30a9e

Summary: One of the utility helper methods commonly used to manage state with Draft.js is the `convertFromHTMLtoContentBlocks` method, which converts an HTML string into a data structure used by Draft.js for tracking state. This is a helpful utility, but it was written in an overly complex way. This commits adds a new simpler implementation of `convertFromHTMLToContentBlocks`.

Reviewed By: flarnie

Differential Revision: D7158000

fbshipit-source-id: 3424cdeb03663dc6c5a194da3d317c6ab97507dc

Summary:
Ran the [rename-unsafe-lifecycles](reactjs/react-codemod@master/transforms/rename-unsafe-lifecycles.js) codemod. For background information on this codemod see [RFC #6](reactjs/rfcs@master/text/0006-static-lifecycle-methods.md) and this [draft ReactJS.org blog post](deploy-preview-596--reactjs.netlify.com/blog/2018/03/15/update-on-async-rendering.html).

bypass-lint
drop-conflicts
allow_many_files

Reviewed By: flarnie

Differential Revision: D7220433

fbshipit-source-id: b0d7572865c002a2be9347dfe1ef7de15d76e800

Summary:
Adding nesting depth to ul/ol nodes.
Changed default depth to -1 (similar to the logic in convertFromHTMLToContentBlocks v1), so the first level of list will be 0 and not 1.

Reviewed By: flarnie

Differential Revision: D7796997

fbshipit-source-id: 47e7f12bc21263eb8480b96b9e9a04e8eb9c934f

…internals

Summary: Upgrade example and Draft.js entry file to use convertFromHTMLToContentBlocks v2 with a GK

Reviewed By: flarnie

Differential Revision: D7823689

fbshipit-source-id: ae55b232e3b40c9cd00445d7e1ca626783a4a34a

Summary:
The old convertFromHTMLToContentBlocks is capping depth to 4, v2 doesn't cap the depth.
DraftEditorContents-core component didn't handle cases of depth bigger then 4.
Similar to the current UI behavior, depth bigger then 4 will be shown as the same depth of 4.

Reviewed By: flarnie

Differential Revision: D7816688

fbshipit-source-id: 8989f0c5fb03bfcffc1e50575e35986d2491c3c2

Summary:
Draft.js have only 1 type of counter-style for ordered lists - the numeric.
Current Draft.js:
pxl.cl/d7zZ

Quip have a 3 different counter-styles, based on the depth:
pxl.cl/d7x6

This can be added by implementing the second argument to the counter function:
 content: counter(ol1) ". ";
to:
  content: counter(ol1,lower-alpha) ". ";

For more info: css-tricks.com/numbering-in-style
Browser support is excellent: developer.mozilla.org/en-US/docs/Web/CSS/list-style-type#Browser_compatibility (for Basic support)

Reviewed By: flarnie

Differential Revision: D7840010

fbshipit-source-id: 6655566baafd9c03468c1b1b7c83bdb5ecf1ada6

Summary:
In some cases, we need to prevent native insertion because native insertion would leave the decorators in the wrong place (and critically – editOnInput's attempt to patch things up would just make things worse and process the insertion twice). This new logic should be correct.

Previously, typing '#' before 'f' in 'x #foo' would result in 'x ###foo' (extra '#' inserted).

Reviewed By: mitermayer

Differential Revision: D7941738

fbshipit-source-id: eeff55ff082fc80c19f76fe1ea915bcbf0e7d86e

…ection

Summary:
Noticed that these helper methods are designed with the assumption they will
only be passed a collapsed selection, but I don't see anything enforcing that
requirement in the code. Since we will be tweaking these helpers and refactoring
things, want to make the code more sturdy and enforce this constraint.

Starting with a 'warning' in case something relies on broken behavior here, but
as a follow-up we should make this an invariant.

Reviewed By: vdurmont, mitermayer

Differential Revision: D9034617

fbshipit-source-id: 378390c308d1ab2657bea7a5cc9cae060e515658

Summary:
Fixes #1830 (bug introduced in #719; this is a proper fix for #398).

* When we're allowing native insertion, we don't want to modify the selection because doing so blocks browser features like spellcheck from working
* In all other cases when typing, we *do* want to force the selection – failing to do this is why the original issue occurred
* We use the `insert-characters` change type for both native and non-native insertions
* Instead of guessing in `EditorState.push` whether to force a selection, accept it as a parameter
* Gate all changes by `draft_non_native_insertion_forces_selection`

I verified with the feature flag disabled (same behavior as before):

* Typing over a character works, and the cursor moves as expected (because of the `chars === currentlySelectedChars` check)
* With editor contents "ABC\ndef", replacing "d", "e", or "f" with the character above *fails* to replace the char (because that check is buggy).

And with the feature flag enabled (new behavior):

* Typing over a character still works (but does so without the buggy check)
* With editor contents "ABC\ndef", replacing "d", "e", or "f" with the character above *succeeds* at replacing the char.

Reviewed By: flarnie

Differential Revision: D9209691

fbshipit-source-id: f63551dbad689391aa9c2a69f1d6ba395b8bf1ac

Summary:
**Summary**

Add a public method, `usesMacOSHeuristics`, to the `KeyBindingUtil` module. This makes it possible to determine how draft-js will interpret certain keyboard events and thus alter the UI accordingly, e.g.;

<img width="499" alt="screenshot 2016-12-13 at 17 58 33" src="cloud.githubusercontent.com/assets/6705160/21150013/dee64566-c15d-11e6-9639-75a39d21d079.png">

I currently achieve this by doing (🙈);

```js
const COMMAND_MODIFIER_CHAR = (navigator && navigator.userAgent.indexOf('Mac') >= 0)
    ? '\u2318' // Mac command key character
    : 'Ctrl'
```
Pull Request resolved: #869

Differential Revision: D9734962

fbshipit-source-id: ed3f3d0a87df51c708fd666fe85bc6acba1ecfee

Summary:
Since draft.js replaces pasted images as a camera emoji to indicate pasted content, text copied as:

{F136101602}

which is copied to clipboard as
```
"<meta charset='utf-8'><span style="color: rgb(29, 33, 41); font-family: system-ui, -apple-system, system-ui, &quot;.SFNSText-Regular&quot;, sans-serif; font-size: 24px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 300; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">hello<span> </span></span><span class="_5mfr _47e3" style="line-height: 0; vertical-align: middle; margin: 0px 1px; font-family: system-ui, -apple-system, system-ui, &quot;.SFNSText-Regular&quot;, sans-serif; color: rgb(29, 33, 41); font-size: 24px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 300; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;"><img class="img" height="24" role="presentation" src="static.xx.fbcdn.net/images/emoji.php/v9/f4a/2/24/1f600.png" width="24" alt="" style="border: 0px; vertical-align: -3px; margin-top: 0px;"><span class="_7oe" style="display: inline; font-size: 0px; width: 0px; margin-bottom: 0px; font-family: inherit;">?</span></span>"
```
essentially `<span><img /><span>...</span></span>`

when pasted, renders as:
{F136101606}

This behavior is not required when pasting images that are for presentation only, so adding the camera emoji is skipped for this use case. This is an update to the functionality added in #1378

Rolling this out with gatekeeper `draftjs_fix_paste_for_img`

Differential Revision: D9333247

fbshipit-source-id: 772229521b4457ea2a6efd726715710c03c4887d

Summary:
**Summary**
- Updated the DraftEntity flow type to be `string`. fixes #868

**Test Plan**
N/A
Pull Request resolved: #1878

Differential Revision: D10188002

fbshipit-source-id: e52da4d8dd708c7ed58e7d6f8c585e86835f1bb2

Summary:
Fixes #1700, which includes a detailed description and reproduction of the issue.

Hopefully it's ok that I refactored the true/false assertions not to use snapshots; I found them confusing and tedious and figured it was probably just an artifact of migrating to Jest a long time ago.
Pull Request resolved: #1811

Differential Revision: D10234643

fbshipit-source-id: 531e45c8fe1708fb440240e1a7bd121cb126cd08

Summary:
**Summary**

Currently pressing Option+Space in Chrome on OSX will cause a nonbreaking space to always be inserted into the editor. This behavior ignores any key bindings that the editor has set.

This change moves the logic which adds the non breaking space to after the point that the key binding function has been run in order to give editors a chance to handle this behavior on their own.

**Test Plan**

This has been tested manually since there are no current tests for the event handlers and no current framework for testing the handlers. We have been running [with this change in our fork of Draft](textioHQ@f4c3aeb) for about seven months without issue.
Pull Request resolved: #1254

Differential Revision: D10241854

fbshipit-source-id: b8fe92a4f76bbb7543efdb3e5deca1dbdbc0960c

Summary:
**Summary**
Fixes issue #1383. Fixes problem which is: onDrop breaks onSelect/onChange events.
Fixes issue #1454 (partial). Fixes problem which is: after first internal drop dragged text will not be moved to target position, but copied.
The solution is to set `editor._internalDrag` to false not during onDragOver events, but after end of drag-n-drop.

**Test Plan**
Attached reproducable videos (on Chrome for Linux)
Issue #1383 before and after:
![1383-before](user-images.githubusercontent.com/3238637/46585340-68ec4100-ca78-11e8-9c2f-c98e7cb381ff.gif)
![1383-after](user-images.githubusercontent.com/3238637/46585344-6c7fc800-ca78-11e8-9c2e-fdac5594d1d0.gif)
Issue #1454 before and after:
![1454-before](user-images.githubusercontent.com/3238637/46585364-9e912a00-ca78-11e8-9c17-5dfcec5a2e16.gif)
![1454-after](user-images.githubusercontent.com/3238637/46585361-9a650c80-ca78-11e8-8b7f-dac6c6af4b23.gif)
Pull Request resolved: #1599

Differential Revision: D10236073

fbshipit-source-id: 3b7b816630f3b5b15931cb53782a1d5b9e9d5121

Summary:
**Summary**

This appears to be standard functionality in text editors. If the list item has no text and the user pressed `Enter`, rather than creating a new list item, the current one should simply be removed. This is how it works in Google Docs, TextEdit, etc.

**Test Plan**

1. Open the Rich Text editor example.
2. Create a list item. Don't add any text to it.
3. Press enter

The list item should be removed.
Pull Request resolved: #769

Reviewed By: flarnie

Differential Revision: D10371552

Pulled By: flarnie

fbshipit-source-id: aa975e465c5cdbb1a8def62ba079545836211152

Summary:
**Summary**

Reverts 7f0cab2 to bring back the `ariaOwneeID` prop. The ARIA property `aria-owns` is required for the combobox ARIA widget, in both ARIA 1.0 and 1.1. Some plugins, for example the Mentions and Emoji plugins, still pass an `ariaOwneeID` prop which at the moment doesn't do anything. Also, without `aria-owns`, some browser / screen reader combinations don't read out the suggestions at all. For more details please refer to the related issue #1736.

Fixes #1736.
Pull Request resolved: #1883

Reviewed By: vdurmont

Differential Revision: D10371390

Pulled By: vdurmont

fbshipit-source-id: 140282124128437e0d8cc9b08490420c3dc81dc1

Summary: If you're at the end of a line and press Ctrl-K (on Mac OS), it should delete the newline (same as if you had just pressed forward-delete). Now it does (and stores the newline in the secondary clipboard, as Ctrl-K always does).

Reviewed By: claudiopro

Differential Revision: D13085302

fbshipit-source-id: b32cfcd41ad4ff482ff71621f98bd6524c415fc5

…verter

Summary:
Added mark tag as recognizable tag used for styling in HTML conversion.

We need this because we need a way to include a custom style for highlighted text (via `span`), which there currently seems to be no support for.

Reference to similar open source pull request with same change: 638f686

Reviewed By: claudiopro

Differential Revision: D13573448

fbshipit-source-id: a72716dd39870d9db8cc0b13d8fcbed683e49063

Summary: This diff aligns the refactored HTML converter with the legacy one to correctly handle <br> tags

Reviewed By: mitermayer

Differential Revision: D14027112

fbshipit-source-id: 68c2ae2272bac4e2d90a72b71cfb43f7b20faa3a

Summary:
Pasting text from Quip results in a space being inserted at the beginning of each new line (except for the first one), due to blocks including \n as a leading character that is then turned into a space.

I couldn't repro the issue with Word flagged in the comment (could be Word on Windows, or one of the older versions of Word?), but just in case I'm only removing the leading \n that is invisible in HTML and leaving the other replacements as is.

Reviewed By: claudiopro

Differential Revision: D14199824

fbshipit-source-id: c6b9cfa72e3f75d9fae485bb87fb5bd40862375a

Summary: Pull Request resolved: #2045

Differential Revision: D14674391

fbshipit-source-id: 431ba174a820532d9727a7d98ddf3d1da7ffafe6

…ustom entities.

Summary:
details are here: #1784
in the comment, nivedita mentioned we need to test this out for intern editor
hence not merging the PR.

since that comment was made back in Jan, so it's probably gonna take a while
for this to be merged into FB codebase. In the mean time this is blocking
CMS Editor's embeded CMS use case. So I figured we should do a branching
to merge the fix just for CMS Editor.

Unfortunately, the logic is pretty deep in the DraftJS stack, so I had to make
a couple changes to pass down the copy paste behavior.

Differential Revision: D14626028

fbshipit-source-id: 4826ea33abf2618835841200af81e10d707aa23b

Summary:
This PR is a new attempt to address #1895

On #2031 I was trying to make compositions work using the data provided by that event, and even though that works well for most operational system, that doesn't work well for Android, where you can make composition updates in multiple places on the same composition transaction.

This PR is an improvement over that PR, in that it uses a DOM mutation observer during the `compositionStart` -> `compositionEnd` interval to detect the changes the user made, and then re-apply those to the ContentState on `compositionEnd`.

This approach is the one used by [Prosemirror](http://prosemirror.net) (see ProseMirror/prosemirror-view@master/src/domobserver.js), which is the only Rich Text Editor I've tried that works well on Android.
Like previously mentioned, it allows multiple mutations on multiple places in the same composition transaction, which was impossible with the previous approach, and would cause DOM<->state inconsistencies in multiple use cases.

The intent of this PR is not to fix every single Android bug, but to have a consistent editing experience on Android without introducing bugs (ideally).

**TODO, known issues:**
- [x] Removing empty line breaks with <backspace> doesn’t remove blocks.
- [x] Mutations on the same block (different leaf nodes) are not being properly applied.
- [x] Selection is not properly updated during composition events
- [ ] Keep `inlineStyleOverride` working with a consistent behavior

**TODO, others:**
- [x] Test on Android Pie v9 API 28
- [x] Test on Android Oreo v8.1 API 27
- [x] Test on Android Oreo v8.0 API 26
- [x] Test on iPhone 12.1 (with Japanese Kana keyboard)
- [x] Test composition events on Chrome Desktop v73
- [x] Test composition on IE11 (I didn't know how to test composition events though)
- [x] Unit tests

There are 3 ways to try out this PR.

Codesandbox: 3ymzzlj9n5.codesandbox.io (uses `draft-js-android-fix-beta.3`)

Use the published [draft-js-android-fix](npmjs.com/package/draft-js-android-fix) package: `yarn install draft-js-android-fix`

Note that this package might not be up-to-date, it's hard for me to guarantee I'll always remember to update the package, but I'll do my best.

The other way is guaranteed to be up-to-date, but has a longer setup:
* run `git clone https://github.com/facebook/draft-js.git`
* run `git remote add fabiomcosta https://github.com/fabiomcosta/draft-js.git`
* run `git fetch fabiomcosta`
* run `git checkout -b attempt_android_fix_with_dom_diff fabiomcosta/attempt_android_fix_with_dom_diff`
* run `yarn install` (or use `npm`)
* run `open examples/draft-0-10-0/rich/rich.html`, or any other example you'd like to test
Pull Request resolved: #2035

Reviewed By: kedromelon

Differential Revision: D14568528

Pulled By: claudiopro

fbshipit-source-id: 16861de52eca41cd98f884b0aecf034213fc1bd0

…ntent

Summary: This diff introduces an undesired behavior introduced by D13085302 where the removeRange operation triggers an error if the selection is collapsed at the end of the last content block.

Reviewed By: elboman

Differential Revision: D15758815

fbshipit-source-id: 0f0c2cc94aed23643efb36a66587189e624addc6

Summary:
Attribute styles defined on a node were permanently added to the persistent set of styles.
This meant that any bold/italic/underline/strikethrough styles would persist until the end of the document, or until a different value was set for it.

This wasn't an issue in `convertFromHTMLToContentBlocks` because it would clone the current styles before passing them off to its children.
Since this was refactored away in `convertFromHTMLToContentBlocks2` (probably for perf reasons), I safely mutated `currentStyle` around its children, in the same way as `inlineStyle`.

Reviewed By: claudiopro

Differential Revision: D15737186

fbshipit-source-id: 494f75da48f9a23a5ece450ab66002f4a3f9c43a

Summary:
Previously, a non-root-level bullet point would be demoted by one level.

i.e.
```
- A
- B
  - C
- D
  - E
    - F
```

would render as

```
- A
- B
- C
- D
- E
  - F
```

I manually tested and verified this only affects `convertFromHTMLToContentBlocks2`, and not `convertFromHTMLToContentBlocks`.

Reviewed By: NoamELB

Differential Revision: D15748960

fbshipit-source-id: e018ac740b622fb13f7053d4d1aa4c4e50a67d00

Summary: This diff renames `convertFromHTMLToContentBlocks` to `convertFromHTMLToContentBlocks_DEPRECATED` to formally declare it deprecated ahead of its removal, and give consumers a heads up that they ought to upgrade to `convertFromHTMLToContentBlocks2` and report back any issues with parsing HTML templates.

Reviewed By: mrkev

Differential Revision: D15844900

fbshipit-source-id: c7077f02627e82814f2429ec80f8a70b1e87aadc

Summary:
When pasting rich (HTML) content into a Draft editor, the generated blocks
are flattened such that they can be represented in the internal state model.
Until a change to the tree-based model is fully implemented, that may cause
formatting to be lost if the content is wrapped in multiple levels of divs,
as the parsing does not traverse them deeply.

Improve the amount of formatting that can be preserved in the current model
by stripping out divs considered 'useless' (with no text or styling), such
that more important elements can be 'brought to the surface' and parsed
in a more pleasant manner.

Reviewed By: claudiopro

Differential Revision: D15923965

fbshipit-source-id: 72824ddba69b5d08374f505187ed4a6ea7c4d573

Summary:
If you drag an image into the draft-js editor it throws an error:

```
insertTextIntoContentState.js:25 Uncaught TypeError: Cannot read property 'length' of null
    at insertTextIntoContentState (insertTextIntoContentState.js:25)
    at Object.replaceText (DraftModifier.js:63)
    at Object.insertText (DraftModifier.js:67)
    at insertTextAtSelection (DraftEditorDragHandler.js:116)
    at onDrop (DraftEditorDragHandler.js:102)
    at DraftEditor.react.js:268
    at HTMLUnknownElement.callCallback (react-dom.development.js:147)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:196)
    at invokeGuardedCallback (react-dom.development.js:250)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:265)
    at executeDispatch (react-dom.development.js:571)
    at executeDispatchesInOrder (react-dom.development.js:596)
    at executeDispatchesAndRelease (react-dom.development.js:695)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:704)
    at forEachAccumulated (react-dom.development.js:676)
    at runEventsInBatch (react-dom.development.js:844)
    at runExtractedEventsInBatch (react-dom.development.js:852)
    at handleTopLevel (react-dom.development.js:5030)
    at batchedUpdates$1 (react-dom.development.js:21469)
    at batchedUpdates (react-dom.development.js:2247)
    at dispatchEvent (react-dom.development.js:5110)
    at react-dom.development.js:21526
    at Object.unstable_runWithPriority (scheduler.development.js:255)
    at interactiveUpdates$1 (react-dom.development.js:21525)
    at interactiveUpdates (react-dom.development.js:2268)
    at dispatchInteractiveEvent (react-dom.development.js:5086)
insertTextIntoContentState @ insertTextIntoContentState.js:25
replaceText @ DraftModifier.js:63
insertText @ DraftModifier.js:67
insertTextAtSelection @ DraftEditorDragHandler.js:116
onDrop @ DraftEditorDragHandler.js:102
(anonymous) @ DraftEditor.react.js:268
callCallback @ react-dom.development.js:147
invokeGuardedCallbackDev @ react-dom.development.js:196
invokeGuardedCallback @ react-dom.development.js:250
invokeGuardedCallbackAndCatchFirstError @ react-dom.development.js:265
executeDispatch @ react-dom.development.js:571
executeDispatchesInOrder @ react-dom.development.js:596
executeDispatchesAndRelease @ react-dom.development.js:695
executeDispatchesAndReleaseTopLevel @ react-dom.development.js:704
forEachAccumulated @ react-dom.development.js:676
runEventsInBatch @ react-dom.development.js:844
runExtractedEventsInBatch @ react-dom.development.js:852
handleTopLevel @ react-dom.development.js:5030
batchedUpdates$1 @ react-dom.development.js:21469
batchedUpdates @ react-dom.development.js:2247
dispatchEvent @ react-dom.development.js:5110
(anonymous) @ react-dom.development.js:21526
unstable_runWithPriority @ scheduler.development.js:255
interactiveUpdates$1 @ react-dom.development.js:21525
interactiveUpdates @ react-dom.development.js:2268
dispatchInteractiveEvent @ react-dom.development.js:5086
```
With this change the editor checks if there is any text and if there is it handles it like normal, if there isn't it does nothing.

Closes: #2116
Pull Request resolved: #2117

Reviewed By: niveditc

Differential Revision: D16132165

Pulled By: claudiopro

fbshipit-source-id: cd9ddc424845df3e9de1de6087201ef83e28ecb0

Summary:
there is a bug in Draft JS replace fragment logic where it replaces
block data directly with the fragment's block data. That causes things like
notice block loses it's data when pasted from other blocks.

The diff introduces a new parameter to allow the data on the block to be merged
instead of replaced. That way we could preserve the original data as well as
merging from the fragment's data (if available).

Note that in our use case, old data take precedence - for exmaple, if you paste
from a "note" notice to a "warning" notice, the resulting notice should still be
warning instead of "note".

Differential Revision: D16167295

fbshipit-source-id: 6e525d2263014e0666928077a71d9d406bd68143

Summary:
**Summary**

This adds a `preserveSelectionOnBlur` prop as per #2123

**Test Plan**

Tests were added for the two possible scenarios. I'm not sure how much to mock in this test because it is just testing a specific branch of code, so I've faked certain details like the rangeCount.

What do you think mrkev claudiopro ?
Pull Request resolved: #2128

Reviewed By: claudiopro

Differential Revision: D16270879

Pulled By: mrkev

fbshipit-source-id: 304af92c1211b8ff95741bff434b4fe3c4b6dd7d

Summary:
this is to address the case where people paste content from quip
or google doc which breaks KM editor.

Differential Revision: D16833432

fbshipit-source-id: cc853284c833f131e11930cc4cf18714809071ac

Summary:
Pull Request resolved: #2163

\u200B (zero space width chars) is put into the blockmap while inserting tokens. Therfore hastext returns true even when there is no text in the input. Updated hastext method to not account for zero space width chars.

Reviewed By: claudiopro

Differential Revision: D16868475

fbshipit-source-id: 1b0c9142c54e9c45d19fde516167ef34d02e719d

Summary:
As figured out in T47552048, the issue of cursor jumping is happening because the draft editor's selection state is not in the correct state. After digging in, I discovered that the draft editor manages this state through the contenteditable div's onSelect event, but it is not being fired in certain cases. So I am changing the code to update the selection state when mouseUp and keyUp events are fired, and this fixes the issue as these events are fired even in those cases where onSelect is not. Although this means that there are some redundant updates to the selection state, this shouldn't cause any bugs.

I suspect this is happening because of some change/bug on how chrome is firing events on contenteditable, since it doesn't repro on firefox and also I couldn't find any code changes that match the bug timeline.

Reviewed By: claudiopro

Differential Revision: D17054885

fbshipit-source-id: 06b1e96629828d4cb1c9cab36c2711c6464f1f3c

Summary:
**Summary**
Makes image entities created with the HTML importer immutable

This diff also adds the `flow` annotation to the `convertFromHTMLToContentBlocks` test case and fixes typechecking failures that are surfaced by its addition.

To support a more modern syntax to handle nullable fields, it adds the `babel/plugin-proposal-optional-chaining` plugin to Babel config.

Fixes #2149

**Test Plan**
Adds tests to verify created entities are immutable
Pull Request resolved: #2184

Reviewed By: j-nolan

Differential Revision: D17474930

Pulled By: claudiopro

fbshipit-source-id: c60ef368ff471914c2e188277a0ecc050115533b

)

Summary:
**Summary**

Bails out early from the `getUpdatedSelectionState` method with previous selection when `anchorLeaf` or `focusLeaf` are null to prevent an error surfaced when using a decorator for emoji inserted between two spans of text entered via IME.

Thanks to robbertbrak for suggesting and cherry-picking a fix from their fork 🎉

Fixes #2187

**Test Plan**
1. Build Draft.js
1. Inject into jsfiddle reported by jdecked jsfiddle.net/36tvhmce
1. Try to repro issues with Pinyin and Hiragana IME
1. Verify there is no error in the console and text is entered normally
Pull Request resolved: #2189

Reviewed By: kedromelon

Differential Revision: D17504999

Pulled By: claudiopro

fbshipit-source-id: dbd2180cf5c1af5bbe1c2b94c50767c58f524dcf

Summary:
**Summary**

Fix instances of the React warning:
```
React.jsx: Spreading a key to JSX is a deprecated pattern. ' +
        'Explicitly pass a key after spreading props in your JSX call. ' +
        'E.g. <ComponentName {...props} key={key} />'
```
originating from [React here](facebook/react@18d2e0c/packages/react/src/ReactElementValidator.js#L366-L373)

This warning occurs when you spread a key with other props. There are probably more instances of this issue but these are the highest firing in our codebase.

**Test Plan**

`npm run lint && npm run test`
Pull Request resolved: #2221

Reviewed By: mitermayer

Differential Revision: D18038272

Pulled By: steveluscher

fbshipit-source-id: 736236601ace92ae1e8d127e10bb35e393fa14b7

…(Fixes issue #2226) (#2240)

Summary:
**Summary**

When passing `createWithContent` a `state` parameter created using `convertFromHTML` from an empty string and `createFromBlockArray`, as shown in the example:

```
const sampleMarkup =
  '<b>Bold text</b>, <i>Italic text</i><br/ ><br />' +
  '<a href="http://www.facebook.com">Example link</a><br /><br/ >' +
  '<img src="image.png" height="112" width="200" />';

const blocksFromHTML = convertFromHTML(sampleMarkup);
const state = ContentState.createFromBlockArray(
  blocksFromHTML.contentBlocks,
  blocksFromHTML.entityMap,
);

this.state = {
  editorState: EditorState.createWithContent(
    state,
    decorator,
  ),
};
```

The following error is thrown:

```
TypeError: Cannot read property 'getKey' of undefined

  84 | EditorState.createWithContent = function createWithContent(contentState, decorator) {
> 85 |   var firstKey = contentState.getBlockMap().first().getKey();
     | ^  86 |   return EditorState.create({
  87 |     currentContent: contentState,
  88 |     undoStack: Stack(),
```
The previous error is generated because `createWithContent` asumes that `contentState.getBlockMap().first()` will return an element, which is wrong for scenarios where the block map is empty. As a consecuence the `getKey();` function in `contentState.getBlockMap().first().getKey();` is executed on `undefined`, thus throwing the error.

The previous scenario is very common if you are planning to use the editor to allow a user to write HTML content which could also be blank, especially as a default value.

**Solution**

In order to make the less amount of modifications to the code, I've added a validation that will run `createEmpty` in case the block map is empty.

**Test Plan**

Open `/draft-js/examples/draft-0-10-0/convertFromHTML/convert.html` and change line #61 from:

`const blocksFromHTML = convertFromHTML(sampleMarkup);`

to:

`const blocksFromHTML = convertFromHTML('');`

No error will be shown.
Pull Request resolved: #2240

Differential Revision: D18247644

Pulled By: mrkev

fbshipit-source-id: 3eb90fd5379e8a2d85efbb2b7b9587ca87701d12

Summary:
Should fix #304.
Thanks andpor.

**Summary**
based on Andrzej's #1223, issue has been there for an incredible 3.5 years. Let's fix this.
Pull Request resolved: #2197

Reviewed By: elboman

Differential Revision: D18314441

Pulled By: mrkev

fbshipit-source-id: 99284101bab838c574341b44b3cfcd935f1dc0e2

Summary:
**Summary**

Takes over and applies requested PR feedback to #1877 by haikyuu.

Refer to original PR for context and discussion.

**Test Plan**

Run some manual smoke tests on the editor running in an iframe as follows:

```
yarn
python3 -m http.server 8080 .
open http://localhost:8080/examples/draft-0-10-0/iframe/iframe.html
```
Pull Request resolved: #1938

Reviewed By: claudiopro

Differential Revision: D13137413

Pulled By: jack-arms

fbshipit-source-id: efcdbabc7d8d2aff4fbebc8b06c22d57756ebc12

Summary:
Fixes an issue introduced by D13137413 where we weren't safely getting the right document for an event target, if the event target is null.

Fixes by using the safer `getCorretDocumentFromNode`, which uses the defualt `document` if the argument is null.

Reviewed By: claudiopro

Differential Revision: D18618225

fbshipit-source-id: bc381a5000318c5065fdf856387dd038b7e04003

Summary:
`_extractTextFromBlockConfigs` was checking the `blockType` property of a `ContentBlockConfig`. However, `ContentBlockConfig` doesn't actually contain a `blockType` property. The right name is just `type`.

This diff fixes that and removes the flow suppression comment. Doing this also fixes an annoying problem where blockquotes (among other things) would have extra newline characters inserted when pasting into the editor.

Reviewed By: mrkev

Differential Revision: D18581836

fbshipit-source-id: 23b2b8a4ea75fd6b7d9a89fd11dc6cc889052d5d

Summary:
Fixes #2082.
Pull Request resolved: #2088

Differential Revision: D18698264

Pulled By: mrkev

fbshipit-source-id: f5f5d4e4a0ff66a9fef62976af8726660411a106

Summary:
Closes #2254

Problem behavior and reasoning behind solution is described in the issue.

The linter issues are unrelated to the file I changed so I left them alone in order to keep this commit atomic.
Pull Request resolved: #2256

Reviewed By: claudiopro

Differential Revision: D18734244

Pulled By: mrkev

fbshipit-source-id: eb5a1a91f7c3f27fced1e37f5822bc3e126fb332

Summary:
*Before* submitting a pull request, please make sure the following is done...

1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure that:
  * The test suite passes (`npm test`)
  * Your code lints (`npm run lint`) and passes Flow (`npm run flow`)
  * You have followed the [testing guidelines](facebook/draft-js/wiki/Testing-for-Pull-Requests)
5. If you haven't already, complete the [CLA](code.facebook.com/cla).

Please use the simple form below as a guideline for describing your pull request.

Thanks for contributing to Draft.js!

-

**Summary**

Fixes #2074
Updated the default block render map to have the section and article tags.
Pull Request resolved: #2212

Reviewed By: claudiopro

Differential Revision: D18246366

Pulled By: mrkev

fbshipit-source-id: 144f7721d92d6efcbb5c969ba992841eb9bd5f15

…selection when there is not one (#2271)

Summary:
**Summary**
Various browsers will throw errors if `selection.getRangeAt(0)` is called when there is no range. To fix this, a check was added to make sure a range exists.

This change was originally suggested [here](#1571) a few years ago. I opted for opening a new PR and adding tests here since that PR seemed stale.

Selection and Range did not work in the test environment, so I had to stub them. I only added functionality for what was needed in the tests I added, but more can be added in the future very easily.
Pull Request resolved: #2271

Differential Revision: D18807105

Pulled By: mrkev

fbshipit-source-id: 0e3b833b8a3267b9a5f17b262b6a0442b6ae5e3d

Summary:
Pull Request resolved: #2285

IE 11 considers the enter keypress that concludes the composition as an input char, which ends up adding a new line to the editor. I am adding code to strip that newline character when processing the mutation event.

Reviewed By: mrkev

Differential Revision: D19141003

fbshipit-source-id: 53848e42d0e2b45d609e6623cc5d5579168b73fe

…at from the chat create view

Summary: When opening a group chat from workplace chat's new message in IE the first invocation of interfaceselection.addRange throws an unspecified error. Remarkably, subsequent invocations work fine and draft editor is able to continue as usual. This typically happens when IE doesn't like something but it is very hard to suss out what the root cause is. So I'm wrapping with a try catch so that this does not crash the draft editor completely.

Reviewed By: danielbuechele

Differential Revision: D19163859

fbshipit-source-id: ded92cae390dfca8d8956a49c1be54b1540b2998

Summary:
# The Problem

`convertFromHTMLToContentBlocks` currently mishandles styles pretty significantly. It has a `currentStyle` attribute that is mutated as the HTML is processed. When processing a node, it determines what styles that node should have (by unioning styes inferred from the tag and styles inferred from the style attribute) and adds them to `currentStyle`. After it's done processing the node, it removes whatever it added.

This has several problems:
## Styles are *never* removed before rendering the children of a node
For example, if you have the following content:
```
<span style="font-weight: bold">
  <span style="font-weight: normal">
    Not bold!
  </span>
</span>
```
then the "Not bold!" text will actually be given the `'BOLD'` style.

## Styles are sometimes removed when they shouldn't be
For example, if you have the following content:
```
<span style="font-weight: bold">
  <span style="font-weight: bold">
    Bold!
  </span>
  <span>
    Still bold!
  </span>
</span>
```
then the "Still bold!" text will *not* be given the `'BOLD'` style.

## Styles from tag override styles from the style attribute

For example, if you have the following content:
```
<b style="font-weight: normal">Not bold!</b>
```
then "Not bold!" will be given the `'BOLD'` style. (In all browsers I've tested, this content would render as the normal font weight, so I'm assuming this should not have the `'BOLD'` style.)

# The Fix
Using a single `OrderedSet` of styles that is mutated as you process nodes can't fix the second issue mentioned above, because it simply does not store enough info to be able to know what styles it should be using at any given time.

So instead of using this attribute, I'm adding a `style` param to `_toBlockConfigs`. When a node has some styling applied to it, we just make a copy of the style object (implicitly, since it's an immutable `OrderedSet`) with the appropriate styles added or removed. When we're done processing the children of that node, we don't need to do any cleanup because the updated style object is simply thrown away.

In addition, we add styles from looking at tags before adding/removing styles based on the actual style attribute. This allows `<b style="font-weight: normal">Not bold!</b>` to actually render as non-bold text.

Reviewed By: mrkev

Differential Revision: D19295374

fbshipit-source-id: 0ba040a9a19de36d716a4fcd6f55bf57077f001e

Summary:
We're gonna use it to remove some findDOMNode usage. This lets you access the actual contentEditable.

In the future, we might be able to remove the `.editor` and `.editorContainer` instance fields, and make them both refs.

Reviewed By: claudiopro

Differential Revision: D19555598

fbshipit-source-id: a86be5370a9fd173b3bb062ecc50cabdf9823b75

Summary:
Browser scrolls to native editors when they get inserted into the DOM. Draft replicates that behavior. However, that behavior is occasionally not what we want at all.

As a result of this, we sometimes have "scroll wars" where different parts of the product code try to restore scroll after others change it. This is a source of bugs.

This adds a first-class way to disable this behavior. I named the prop a bit generically so that if I find more such cases, I can disable them too.

Reviewed By: steveluscher

Differential Revision: D19568181

fbshipit-source-id: ed4db22abebbdae1b11d84e1bf6d7772a840b3da

#2330)

Summary:
#2204
Pull Request resolved: #2330

Reviewed By: claudiopro

Differential Revision: D20582792

Pulled By: mrkev

fbshipit-source-id: d96beaa1617ef82ba5663637f5daad254d9b17f7

Summary: Needed for writing assistance. More correct than D20659377 IMO.

Reviewed By: raedle

Differential Revision: D20713362

fbshipit-source-id: 77b118ceb50eb50b385e0385c2cd07169512ddc4

Summary:
DraftJS's paste handling is a little bit weird right now.

Suppose you have some arbitrary HTML that looks like this
```
<div>
  <h1>Some h1 content</h1>
  <span>Some other content</span>
</div>
```
or a DraftJS editor with an H1 block and an unstyled block with the same contents.

In either case, if you select both blocks of this content and paste into an empty editor, you get two blocks: one H1 and one unstyled.

But if you select *only the first block* and paste into an empty editor, you get a single unstyled block.

When you are inserting multiple blocks, `insertFragmentIntoContentState` checks whether to use the type of the target block or the pasted block based on whether the target block is empty:
```
return block.merge({
  text: headText + appendToHead.getText(),
  characterList: headCharacters.concat(appendToHead.getCharacterList()),
  type: headText ? block.getType() : appendToHead.getType(),
  data: appendToHead.getData(),
});
```
our.intern.facebook.com/intern/diffusion/WWW/browse/master/html/shared/draft-js/model/transaction/insertFragmentIntoContentState.js?commit=1001924671&lines=105

But when inserting a single block, this logic is not used.

This diff adds a similar check in `updateExistingBlock`, which handles the single block case. The difference is that the single block case **only** uses the inserted text's block type if the target block is **unstyled**. I did this because I thought it would be weird if you tried to paste text into a bulleted list or a block quote and it removed the styling.

Reviewed By: mrkev

Differential Revision: D20774564

fbshipit-source-id: c1490e17e5ecacea7891f9c7a5880f7eab8831e7

Summary:
# Facebook

CoEditing Prototype relies on syncing the state of the editor between different users so that we can propagate changes between them and hence have the document state synced between users.

**How DraftEntity Works**

`DraftEntity`, when creating a new entity uses incremental numbers as the key ([source](master/src/model/entity/DraftEntity.js#L211)) which can be a problem as two users can simultaneously create entity with the same id, say `6`, with different links thereby causing the document sync to go out of sync.

**Change**

- This diff changes how the keys are generated for new entities. Instead of incremental integers, we create a unique ID (using `uuid()`) and use that as the ID.
- Also exposes `getAll` and `loadWith..` functions that are used in subsequent diffs to get the map of entities and share them with other users and when a new updated map is received, load `DraftEntity` with that. (these changes have been tested already end to end at the top of the stack).

Reviewed By: mrkev

Differential Revision: D20495349

fbshipit-source-id: b65ba740b2c570318b6a471f47bdbf571acf1d5d

Summary:
# Facebook

Co-Editing Prototype is based on the approach of serializing the DraftJS state and syncing the states between users through GraphQL subscription. This is done on a node-by-node basis. Users lock the nodes they are editing and send updates to the other users when they update a node. They also receive broadcast from other users for the nodes those users updated.

The above approach requires serialization of DraftJS's `EditorState` and the ability to recreate this state (and it's hierarchy of Immutable JS records like `ContentState`, `BlockMap` etc) when loading an update from other user. This diff adds a `fromJS()` API (following the ImmutableJS terminology) to all the DraftJS model objects so that they can be constructed from a plain JS object (received post de-serialization).

Reviewed By: mrkev

Differential Revision: D20625291

fbshipit-source-id: d3f6c028b351dc19a5c352998884869b7158a435

Summary: Making the `createContentBlockFromJS` in `ContentState` public for re-usability.

Differential Revision: D21064309

fbshipit-source-id: bbbd6415631401c1cda91b58152a5e7b46d5ce05

Summary:
- This will allow html anchor tags with "tel:" prefixed hrefs to be rendered as links using the convertFromHTML method

*Before* submitting a pull request, please make sure the following is done...

1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure that:
  * The test suite passes (`npm test`)
  * Your code lints (`npm run lint`) and passes Flow (`npm run flow`)
  * You have followed the [testing guidelines](facebook/draft-js/wiki/Testing-for-Pull-Requests)
5. If you haven't already, complete the [CLA](code.facebook.com/cla).

Please use the simple form below as a guideline for describing your pull request.

Thanks for contributing to Draft.js!

-

**Summary**

[...]

**Test Plan**

[...]
Pull Request resolved: #2365

Reviewed By: creedarky

Differential Revision: D21318447

Pulled By: mrkev

fbshipit-source-id: d352eb7c731724dfe80e6c86a882f7b59ac88520

Summary:
In Safari, the placeholder text sometimes wraps into multiple lines before it reaches the full width of the editor.
The addition of `width: 100%;` prevents the absolutely-positioned placeholder from trying to "shrink-wrap", which causes the unnecessarily wrapping.
Steps to reproduce:
1. Open the editor with a placeholder that takes up >50% but <100% of the editor width in Safari.
2. Type a character.
3. Press backspace.

*Before* submitting a pull request, please make sure the following is done...

1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure that:
  * The test suite passes (`npm test`)
  * Your code lints (`npm run lint`) and passes Flow (`npm run flow`)
  * You have followed the [testing guidelines](facebook/draft-js/wiki/Testing-for-Pull-Requests)
5. If you haven't already, complete the [CLA](code.facebook.com/cla).

Please use the simple form below as a guideline for describing your pull request.

Thanks for contributing to Draft.js!

-

**Summary**

[...]

**Test Plan**

[...]
Pull Request resolved: #2392

Reviewed By: fryn

Differential Revision: D21319038

Pulled By: mrkev

fbshipit-source-id: b03c8afa47873ea210207aadb0225db8801bd84e

…2414)

Summary:
All info is in the #2413 and this [Bugzilla issue](bugzilla.mozilla.org/show_bug.cgi?id=1625475).

Noteworthy from that Bugzilla thread is [comment 16](bugzilla.mozilla.org/show_bug.cgi?id=1625475#c16):

> I added a selectionchange listener to the document of Twitter, and I tried reproducing this with the STR in comment 10. Then, I confirmed that selectionchange event is fired as expected both on Firefox (Nightly) and Chrome (Release) when I click middle of the text node. So, **it might be a bug of React if the onSelect is not called as expected...**

This is worth future investigation, but for now let's just fix the bug.
Pull Request resolved: #2414

Reviewed By: kedromelon

Differential Revision: D21443875

Pulled By: mrkev

fbshipit-source-id: 8bd099ddc44e3c4cdac679e1d605c4da5146c1e8

Summary:
Inline styles were not being parsed correctly for code styles, because snippets copied from other posts only use HTML fontFamily properties to make them different.

This diff adds some code to detect those code snippets.

Differential Revision: D21662325

fbshipit-source-id: 75ffee4a91af7036033eeaaa4985111d02dd9443

Summary:
Currently it's not possible to have draft-js *not* emit an `aria-describedby` attribute. This diff allows the developer to remove it.

This attribute points to the generated DOM id of the placeholder. Currently even if no placeholder was specified **[minor bug]**.

I will need this in order to complete T67720986. It will also resolve this [GitHub issue](#1739).

Fixing the GitHub issue meant that I needed a way to have the generated placeholder ID as well as a second specified one. The special token "{{PLACEHOLDER}}" can be used inside the prop to be replaced with that generated ID.

Fixes #1739

Reviewed By: claudiopro

Differential Revision: D21808668

fbshipit-source-id: c27fe0fa8237518f1e2b6830cc8a3e13b3a9d8c7

Summary:
Fixes #2093.
Pull Request resolved: #2094

Reviewed By: claudiopro

Differential Revision: D21770987

Pulled By: mrkev

fbshipit-source-id: f198a89ce2eae69328daa5ce917085ce0d726dba

Summary: - Adds api to create editor state using text string

Differential Revision: D22628246

fbshipit-source-id: e1f1c4bcc68c780de6edf68e407c196bf4c836e1

Summary:
I got a bug report today where someone was trying to copy/paste some content and nothing happened at all. I discovered that this was due to a bad link in her content, something like this:

```
<a href="https:// https://www.facebook.com">Faceboook</a>
```

In Chrome, this passes all the checks in `isValidAnchor`, but throws an error later on this line inside `_addAnchorNode`:
```
entityConfig.url = new URI(anchor.href).toString();
```
To account for this, I added an explicit `URI.tryParseURI` inside `isValidAnchor`.

Reviewed By: claudiopro

Differential Revision: D22601322

fbshipit-source-id: 61cf050bb6e4a31bbe95995ad3f57e8f39a1d954

Summary:
A missing use case for draft i've ran into a couple times is that when text is pasted, there are ways to override the default paste handler and do your own thing. Overriding the default paste handler means you have to manage your own fragment, have logic to handle html potentially, and then insert the blocks you generate in the proper place relative to the cursor and selection. More often than not, this seems overkill?

An example: (and the reason I'm posting this RFC) is that i'm trying to turn leading tabs into spaces when pasting markdown lists, since they can't be parsed. Users can't actually _type_ a tab so this is only a problem on pastes. Reimplementing the paste handler for this is doable but using the proposed method, it's implementation becomes a oneliner.

## Precedent

There's some precedent to this type of handler. `blockRendererFn` and `blockStyleFn` both plug into a similar way, overriding the default implementation.

Then  `handlePastedText` of course works similarly and I decided to copy its signature, when it comes to naming all `handle*` functions return a handle, which is not what we want in this case.

## Q's

Handling html might be a bit smelly? it is doable but you really don't wanna transform raw html to raw html, at that point you do wanna replace the paste handler.
What I've done is that it's the responsibility of `formatPastedText` to pass the html result through or eat it up and return undefined, formatting only the static text.
I'd be cool with just assuming that if `formatPastedText` exists, we ignore `html` automatically, and that simplifies the signature

Reviewed By: claudiopro

Differential Revision: D22574367

fbshipit-source-id: afe1fac1bb11328e354805161cf9489a77245eff