Correct usage of jira-editor-core from Atlaskit (Richt-Text-Editor) in p2 environment

Hey there,

Currently I’m about to refactor the UI of my plugin, I read a few blogs where some developer use react to implement the UI, which inspiried me to do it as well. Actually it works pretty fine, but I have an issue when I try to implement a RTE (Rich-Text-Editor).

First of all, I implemented a component for the RTE based on the atlaskit component

In my view, the RTE is rendered just like I expected and it actually works good.

Now, when I’m typping into the RTE and hit the ‘c’ key, the “Create-an-Issue”-View will pop up…So every key which is an actual shortcut will open a new dialog. Does anyone knows how to use the editor-core component so that it will be rendered as a valid input-field?

Here is my react-component:

export default class EditorTest extends Component{

        return (
                    <div style={{ padding: '20px' }}>
                            placeholder="What do you want to say?"
                              allowColumnResizing: true,
                              allowMergeCells: true,
                              allowNumberColumn: true,
                              allowBackgroundColor: true,
                              allowHeaderRow: true,
                              allowHeaderColumn: true,
                              permittedLayouts: 'all',
                              stickToolbarToBottom: true,
                            contentTransformerProvider={schema =>
                            new JIRATransformer(schema)


Hi, @M.Abdel-Mola, were you able so solve this issue?

Hi @M.Abdel-Mola

Yes we’ve had the same problem. I believe the issue is that the editor uses an editable div rather than a text area so Jira doesn’t recognise it as a field.

A solution we use is to wrap usages of the editor in another component that disables the shortcuts for its children. Something along the lines of this:

import React, { PureComponent } from "react";

class ShortcutBoundary extends PureComponent {
    constructor(props) {
        this.wrapperNode = React.createRef();

    componentDidMount() {
        const { current } = this.wrapperNode;
        if (current && typeof AJS !== "undefined") {
            AJS.$(current).on("aui:keypress", this.preventKeyboardShortcut);

    componentWillUnmount() {
        const { current } = this.wrapperNode;
        if (current && typeof AJS !== "undefined") {
            AJS.$(current).off("aui:keypress", this.preventKeyboardShortcut);

    render() {
        return (
            <div ref={this.wrapperNode}>

    private preventKeyboardShortcut = e => e.stopPropagation();

export default ShortcutBoundary;



We recently ran into this in Confluence as well, FWIW. I’m not sure if the root cause is the same or similarly solvable with Jared’s (very elegant) solution, but there it’s a problem with shortcut keys typed into an RTE being swallowed by jquery’s hotkeys plugin, which does not suppress such events in contenteditable components. Our workaround is an ugly hack, but I will post it here just in case it helps anyone coming at this from a different angle:

      var add = window.jQuery.event.special.keypress.add;
      window.jQuery.event.special.keypress.add = function (handleObj) {
        var result =, handleObj);
        var handler = handleObj.handler;
        handleObj.handler = function (e) {
          if ( && this !== && === 'true') return;
          return, e);
        return result;

Running that as early as possible on page load (not waiting for DOMReady) will fix it for all contenteditables on the page (at least in Confluence 6).