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

Missing Event object when observing editableInput events on link addition #1153

Open
suexID opened this issue Jul 21, 2016 · 7 comments
Open

Comments

@suexID
Copy link

suexID commented Jul 21, 2016

Description

Hi! We're working on a full WYSIYWG editor solution to a client which uses the text-editing capabilities of the MediumEditor along with 3rd party and self-coded extensions. We're listening to editableInputevents to continously update a CodeMirror editor with the HTML source of what the user edits in MediumEditor and we noticed while inserting a link to a document firest the editableInput event but the event doesn't expose the usual Eventobject just an empty one.

Steps to reproduce

  1. Subscribe to editableInput events
  2. Type something into the MediumEditor or modify styles of existing elements (eg.: make a text bold)
  3. An editableInputevent firest and you can see the Event object with target attribute in place
  4. Insert a link via the provided toolbar
  5. An editableInputevent firest but the Eventobject is empty and doesn't contain a target attribute

Expected behavior: An Eventobject should be available with target attribute

Actual behavior: An empty Objectis available without any context

Link to an example: https://jsfiddle.net/qn1aqqc5/

Versions

  • medium-editor: 5.21.0
  • browser: Google Chrome 51.0.2704.103 m
  • OS: Windows 10
@nmielnik
Copy link
Member

@suexID my first question is, have you considered sharing any of those custom extensions with the rest of us? If you have any of them shared as open-source projects/modules, we would love to call them out in our documentation and our landing page 😄

Regarding the editableInput event, we've run into this issue with a few different events. The problem is that there are certain times when we need to manually trigger these custom events to deal with gaps in browser support. For instance, IE has never triggered the input event for contenteditable elements at all. MediumEditor has a whole bunch of crazy code to detect all the cases when the user may have edited the editor to simulate this event. However, that means in IE there will be many cases where when editableInput fires there isn't a native Event object to attach to it (and when there is, it's something like keypress or selectionChange).

In this case, there is a bunch of custom logic within medium-editor for inserting links consistently in a wide variety of use cases. Some of this logic would trigger the editableInput event to fire multiple times while the content of the editor is not in a valid state. Thus, when inserting a link, the code actually disables triggering of editableInput (code here) and then upon completion of all the logic, re-enables the editableInput event and triggers it manually (code here).

There are other cases with other events where we've run into this issue. It's not clear what the right thing to do is, and I've personally gone back and forth between whether the editor should pass the native browser Event whenever it has access to it, or purposefully not including the native Event object in favor of always being consistent.

Let me know if you have any thoughts about this, or perhaps you could describe what properties of the Event you need and maybe we can ensure that all custom events will expose those properties (the code already ensures that the currentTarget is always passed, as well as the editor element which received the event. We could add more properties on to that).

@j0k3r
Copy link
Contributor

j0k3r commented Jan 24, 2017

This issue is fairly old and there hasn't been much activity on it. Closing, but please re-open if it still occurs.

@j0k3r j0k3r closed this as completed Jan 24, 2017
@nmielnik
Copy link
Member

nmielnik commented Feb 9, 2017

I think this issue is worth leaving open as this can be a potential headache for people. I didn't feel great about the solution and would definitely be open to suggestions/recommendations on a better way to standardize the signature of our custom event triggering logic.

@nmielnik nmielnik reopened this Feb 9, 2017
@janwirth
Copy link

janwirth commented May 1, 2017

I also came across this event. Currently working on @franzskuffka/vue-medium-editor and had this issue during testing. So it would be a great help if we could sort this out. I have the gut feeling that this will come bouncing back to me in a short while.

I would love to help out but I am afraid I have to too little knowledge of the architecture to contribute right here.

@jackbarham
Copy link

Has anyone found a solution to this?

@junerockwell
Copy link

I am currently having issues with this.

@janwirth
Copy link

Just letting you know that this bug was reported for franzskuffka/vue-medium-editor quite a few times now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants