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.
editableInputevent firest and you can see the Event object with target attribute in placeeditableInputevent firest but the Eventobject is empty and doesn't contain a target attributeExpected 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/
@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).
This issue is fairly old and there hasn't been much activity on it. Closing, but please re-open if it still occurs.
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.
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.
Has anyone found a solution to this?
I am currently having issues with this.
Just letting you know that this bug was reported for franzskuffka/vue-medium-editor quite a few times now.