Cannot read property 'body' of undefined exception since TinyMCE 4.3.13 - works with TinyMCE 4.3.12

[HeroBart]

When doing a bower update, you now get TinyMCE 4.3.13 rather than 4.3.12 (since a couple of hours). This causes the exception "Cannot read property 'body' of undefined" for me.
As a workaround, I've installed 4.3.12 via my own bower.json again. That solved the problem for now. You may want to look into why 4.3.13 doesn't work with ui-tinymce - perhaps report issues to tinyMCE directly if you find something.

[Endellur]

I am also getting this error, had to revert back to 4.3.12.

[adrianorsouza]

Had the same issue today with tinymce v4.3.13 as @Kimpossibru said manually add v4.3.12 to bower.json works fine.

In my case this error appears when I set the options attribute like so: ui-tinymce="tinymceOptions" without options set it works fine with v4.3.13.

[pboiseau]

Got the same error on v4.3.13 but work fine in v4.3.12

[jbrizio]

Mee too! With the version 4.3.12 Work fine

[Lezeper]

Got same error on latest version.

[deeg]

Sorry for the delay, I will look at this later today and see if we can fix it.

[soniccat]

@deeg while trying to figure out the reasons of the crash I got that Editior.init call happens later than toggleDisable by timer. And after toggleDisable call in getWin I have empty self.iframeElement. And the crash happens here because of empty body

tinyInstance.getBody().setAttribute('contenteditable', true);

[mja-maia]

the same error here

[jgerlach]

Any progress on this?

[guilherme6191]

+1

[comm1x]

+1, still has problem on 4.3.13

[pcunha03]

+1

[Jony-Y]

+1

[ghost]

+1
Btw, it's still a problem with tinyMCE latest release, v4.4

[TanguyBaudrin]

Same issue for me, with latest release

[alvachien]

+1

Same issue occurs in tinymce V4.4.

[SteveyPugs]

+1

[ymind]

+1

[rashdeva]

+1

[moritzpflaum]

I made a plnkr showing the issue:
http://plnkr.co/edit/R7oHmGcRkKz5ZZXSFo9h

And one showing it fixed:
http://plnkr.co/edit/F1QJlRPN8M04n3yNCgm5

The tests fail because of the line
beforeEach(module('ui.tinymce'));

which resets the variable generatedIds to zero before every test, resulting in duplicate ids in the test DOM. If it is replaced with something global, the tests pass. This should not happen in non-test use, I think. I just don't know how to tell jasmine to load the module only once.

[thomasvnl]

@moritzpflaum Thank you, just what I needed to fix the error.

[TanguyBaudrin]

@moritzpflaum Thanks a lot, working for me too ;)

[guilherme6191]

I didn't quite get it. It does not only happen in a test env.

What exactly is the change to fix this?

[reginaldocmrg]

In my case It was solved, in Angular2, using setTimeout.

[moritzpflaum]

@guilherme6191
The issue happens in production.
What only happens in the environment of the unit tests is the unit tests failing, because the angular-directive definition is run multiple times and always resets the "unique" counter for the id.

This is not a problem by itself, but the unit tests continue to append directives with the same '0' value id to the same DOM.
This makes tinymce mess up (by destroying the tinymce instance with id '0' while another test just initalized an instance with that same id) and causes the tests to fail.

The issue mentioned in #264 is fixed by using the new tinymce-init-promise when available.
Once the tests are fixed regarding the 'unique id' issue, they will pass using the promise.

I hope this makes sense.

[thomasvnl]

For me it happened in development mode when running an angularjs app with
grunt.

Op vr 22 jul. 2016 20:04 schreef moritzpflaum notifications@github.com:

@guilherme6191 https://github.com/guilherme6191
The issue happens in production.
What only happens in the environment of the unit tests is the unit tests
failing, because the angular-directive definition is run multiple times and
always resets the "unique" counter for the id.

This is not a problem by itself, but the unit tests continue to append
directives with the same '0' value id to the same DOM.
This makes tinymce mess up (by destroying the tinymce instance with id '0'
while another test just initalized an instance with that same id) and
causes the tests to fail.

The issue mentioned in #264
#264 is fixed by using
the new tinymce-init-promise when available.
Once the tests are fixed regarding the 'unique id' issue, they will pass
using the promise.

I hope this makes sense.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#264 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACtO9x1Jc1tVVTAnUDu2jNenZi7kPe9Bks5qYQZKgaJpZM4IxCL2
.

[KRaymundus]

I had the same problem, solved it by commenting line 142:
toggleDisable(scope.$eval(attrs.ngDisabled));

[CyborgMaster]

I appears to me that @moritzpflaum, may have a fix. Are we waiting for a PR from him? I downgraded to TinyMCE 4.3.12 in the meantime.

[moritzpflaum]

@CyborgMaster I made a PR and it's passing CI.
Someone just needs to accept & merge it. There are some other issues/PRs, too.

[bobzurad]

@moritzpflaum The files in the two plnkr's you posted have the same exact code. What's the difference?

I took @KRaymundus' advice and commented out line 142 to fix it.

Thanks everyone!

[Rouche]

Did the solution explained here and fixed it:
tinymce/tinymce#2722

[insidewhy]

I reverted back to 4.3.12 via bower install --save tinymce-dist#4.3.12 but after running that bower installs to a folder tinymce (not tinymce-dist) and from then on every time I run bower install it gets tinymce-dist as well, leaving me with two versions of tinymce, one with a -dist prefix at the broken version and the one I want.

[insidewhy]

Ah bower install rewrites the bower.json entry according to the name in bower.json so you have to edit the file after running this and then run bower install again.

[zero-degrees]

Commenting out the toggleDisable line isn't a good solution. I submitted a PR for a more robust fix that waits for TinyMCE to start up.

[asaarnak]

Any progress?

[zero-degrees]

Yes. It works reliably for me, and I submitted a PR. There is a failing
test, but that appears to be a preexisting issue.

On Sep 13, 2016 9:20 AM, "asaarnak" notifications@github.com wrote:

Any progress?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#264 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHjEyEKHQH-bAoEDXc4ScIZVgxLSYDcFks5qprEggaJpZM4IxCL2
.