Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

This doesn't seem to fix the problem described in the ticket

(Notice, there's still no [readonly](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly) property on the textarea)

react-ace isn't the most accessible thing so there isn't an API to do this, we have to mutate the dom after render to do this. (Kibana example, though I did mess up a little, the value of readonly should be readonly not true)

Fixed it, by updating ace to 8.0.0.
Please recheck @myasonik

jenkins test this

Preview documentation changes for this PR: https://eui.elastic.co/pr_2967/

Without updating react-ace the workaround to get the readonly property is to do a post-render DOM update

@myasonik I am trying to restore highlighting

@thompsongl I have fixed syntax validation ,highlight

Was a readOnly feature the reason for the version update, or can we continue to use react-ace@7.x and reinstate the brace imports?

we should go with newer version as it major part was Removing brace as a dependency for ace-builds, which builds it's own integrated styles,supports
https://github.com/securingsincity/react-ace/blob/master/CHANGELOG.md

We'll need to label this as a breaking change because of the brace to ace-build dependency change. Kibana (and other consumers) has brace import statements alongside usage of EuiCodeEditor.
@chandlerprall can you think of any other potential impacts here?

brace vs. ace-build could have unintended side effects in:

• content security policy support ([DISCUSS] react-ace/brace + Content Security Policy #1710)
• how the theme and/mode is loaded (e.g. import them before the editor import in brace's AMD/UMD way, are they dynamically loaded with another fetch request, etc)

It's been too long since I've looked into the differences in the various ace packages, so I don't know what I may be mis-attributing to another package, and we'd need a full exploration of these changes to know.

Another option, given:

Without updating react-ace the workaround to get the readonly property is to do a post-render DOM update

is related to #2961 where we're already exploring dynamic attribution setting after mount

Maybe we just do this as a post-render update and table the package update until we can do a full test that it doesn't break anything

Right, I think I'd prefer avoiding the package update if we're planning on supplementing attributes anyway.

Closing this in favor of post-render, dynamic attribute supplementation (see #2961)