-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
disableEditing allows for copy, paste, and cut #572
Labels
Comments
+1 thanks for reporting. Suspending the editor's |
bantic
added a commit
that referenced
this issue
Aug 17, 2017
Previously, manual (as opposed to programmatic) editing was being prevented for an editor after calling `#disableEditing` by setting "contenteditable" back to false for the editor. This prevents the browser from sending most of the edit-related events (keyup, keydown, etc) that occur when editing manually. But some events (like paste) are still emitted by the browser even though "contenteditable" is false. This change calls `EventManager#stop` when editing is disabled, and internally the event manager ignores all events when it is stopped. Also some rearrangement Other changes * Add test for triggering paste event in a disabled editor * add assertion `assert.isBlank` * better assertion actual/expected values for `hasElement` and `hasNoElement` * add test helper `getData` (for parity with the `setData` in element-utils and to avoid using jQuery's `.data()` method) * consolidate the editing-disabled tests into a new suite * make `editor#render` call `disableEditing` or `enableEditing` after it sets `hasRendered` to ensure that the event manager is stopped if the user calls `editor.disableEditing()` before calling `editor.render()` Fixes #572
bantic
added a commit
that referenced
this issue
Aug 17, 2017
Previously, manual (as opposed to programmatic) editing was being prevented for an editor after calling `#disableEditing` by setting "contenteditable" back to false for the editor. This prevents the browser from sending most of the edit-related events (keyup, keydown, etc) that occur when editing manually. But some events (like paste) are still emitted by the browser even though "contenteditable" is false. This change calls `EventManager#stop` when editing is disabled, and internally the event manager ignores all events when it is stopped. Also some rearrangement Other changes * Change editor's internal `isEditable` prop to default to true rather than null (incidentally allows a user to specify that an editor should start disabled by passing in that prop to the constructor) * Add test for triggering paste event in a disabled editor * add assertion `assert.isBlank` * better assertion actual/expected values for `hasElement` and `hasNoElement` * add test helper `getData` (for parity with the `setData` in element-utils and to avoid using jQuery's `.data()` method) * consolidate the editing-disabled tests into a new suite * make `editor#render` call `disableEditing` or `enableEditing` after it sets `hasRendered` to ensure that the event manager is stopped if the user calls `editor.disableEditing()` before calling `editor.render()` Fixes #572
bantic
added a commit
that referenced
this issue
Aug 17, 2017
Previously, manual (as opposed to programmatic) editing was being prevented for an editor after calling `#disableEditing` by setting "contenteditable" back to false for the editor's element. This prevents the browser from sending most of the edit-related events (keyup, keydown, etc) that occur when editing manually. But some events (like paste) are still emitted by the browser even though "contenteditable" is false. This change calls `EventManager#stop` when editing is disabled, and internally the event manager ignores all events when it is stopped. Also some rearrangement Other changes * Change editor's internal `isEditable` prop to default to true rather than null (incidentally allows a user to specify that an editor should start disabled by passing in that prop to the constructor) * Add test for triggering paste event in a disabled editor * add assertion `assert.isBlank` * better assertion actual/expected values for `hasElement` and `hasNoElement` * add test helper `getData` (for parity with the `setData` in element-utils and to avoid using jQuery's `.data()` method) * consolidate the editing-disabled tests into a new suite * make `editor#render` call `disableEditing` or `enableEditing` after it sets `hasRendered` to ensure that the event manager is stopped if the user calls `editor.disableEditing()` before calling `editor.render()` Fixes #572
bantic
added a commit
that referenced
this issue
Aug 17, 2017
…573) Previously, manual (as opposed to programmatic) editing was being prevented for an editor after calling `#disableEditing` by setting "contenteditable" back to false for the editor's element. This prevents the browser from sending most of the edit-related events (keyup, keydown, etc) that occur when editing manually. But some events (like paste) are still emitted by the browser even though "contenteditable" is false. This change calls `EventManager#stop` when editing is disabled, and internally the event manager ignores all events when it is stopped. Also some rearrangement Other changes * Change editor's internal `isEditable` prop to default to true rather than null (incidentally allows a user to specify that an editor should start disabled by passing in that prop to the constructor) * Add test for triggering paste event in a disabled editor * add assertion `assert.isBlank` * better assertion actual/expected values for `hasElement` and `hasNoElement` * add test helper `getData` (for parity with the `setData` in element-utils and to avoid using jQuery's `.data()` method) * consolidate the editing-disabled tests into a new suite * make `editor#render` call `disableEditing` or `enableEditing` after it sets `hasRendered` to ensure that the event manager is stopped if the user calls `editor.disableEditing()` before calling `editor.render()` Fixes #572
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At Bustle we have writers accidentally pasting values into mobiledoc bodies that are created with
disableEditing
called. The writers are then unable to delete the text; however, it can be removed with cutCode:
We are using Ember Mobiledoc Editor
v0.5.12
, with settingsisEditingDisabled=true
in the template, which triggersdisableEditing
Steps to reproduce:
disableEditing
The text was updated successfully, but these errors were encountered: