Skip to content
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

Closed
tsiege opened this issue Aug 17, 2017 · 1 comment
Closed

disableEditing allows for copy, paste, and cut #572

tsiege opened this issue Aug 17, 2017 · 1 comment
Assignees
Labels

Comments

@tsiege
Copy link

tsiege commented Aug 17, 2017

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 cut

Code:
We are using Ember Mobiledoc Editor v0.5.12, with settings isEditingDisabled=true in the template, which triggers disableEditing

Steps to reproduce:

  • Create new mobiledoc editor with disableEditing
  • Click on the body (no cursor should appear)
  • Paste text
  • Highlighting text and deleting does nothing
  • Highlighting text and cut to remove text
@tsiege tsiege added the bug label Aug 17, 2017
@bantic
Copy link
Collaborator

bantic commented Aug 17, 2017

+1 thanks for reporting. Suspending the editor's EventManager altogether when editing is disabled seems like a good idea. I'll issue a PR

@bantic bantic self-assigned this Aug 17, 2017
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
Labels
Projects
None yet
Development

No branches or pull requests

2 participants