problem

The body element of the editors iframe will be reset in some circumstances. The Editor is then not usable anymore.

Currently only reproducible with activated MatchRessource Panel, and only in about 75% of the cases.

chrome

In google chrome this leads to that error message:
Uncaught TypeError: Cannot read property 'match' of null
at constructor.syncValue (ext-all-debug.js:194368)
at constructor.getValue (ext-all-debug.js:194397)
at constructor.handleElementVisible (MinMaxLength.js?_dc=1523536967187:122)
at constructor.<anonymous> (StatusStrip.js?_dc=1523536966479:85)
at constructor.each (ext-all-debug.js:42030)
at constructor.setRecordAndVisible (StatusStrip.js?_dc=1523536966479:82)
at constructor.onSegmentGridBeforeEdit (Segments.js?_dc=1523536966479:259)
at constructor.fire (ext-all-debug.js:20731)
at constructor.dispatch (ext-all-debug.js:57952)
at constructor.callParent (ext-all-debug.js:12493)

firefox

reason

The logical reason for this misbehaviour is TRANSLATE-1130 which initializes the HtmlEditor directly after rendering the page, and the adding of the MatchResource panel. Since the MatchResource panel is added asynchronously after the AJAX call fetching the associated match resources is finished, this issue happens (if the request was a little bit slower) or it happens not if the request was a little bit faster.

The technical reason is the same as in EXT6UPD-49, DOM Manipulation of the DOM structure holding the HTMLEditors iframe. Here the reason is the adding of the MatchResource panel into the viewport. This leads to DOM Manipulation affecting indirectly the iframe, which then results in a reset of the iframe (https://stackoverflow.com/questions/8318264/how-to-move-an-iframe-in-the-dom-without-losing-its-state?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa).

In general the application does DOM Manipulation all the time, but mostly not affecting the iframe.

aleksandar we had a similar issue in VisualReview - not really reproducible.

solution

Since we need the preloading of the HtmlEditor for using SVG instead PNGs as img tags not using the preloading is no solution. Also it can happen in the future by adding new features making DOM Manipulation at other places in the application causing similar issues.

So the approach of valid solution is to check the load event of the iframe. If the iframe is reset a load is also triggered. If we set content then this is not the case.

That means, in the case of a load we check if the body contains all it needs, if not we reinit the iframe.