JS error with elements in "allowed HTML tags" that can't be direct descendants of a div

There are no errors or any feedback why it is not working.

You're basically just saying "it does not work".

Look at CKEditorPluginInterface and all of its implementations. You'll find plenty, plenty of examples that way.

Please edit your comment so that it becomes at least somewhat legible. I'm pretty sure an ICT manager is able to write better English and better formatted texts than this.

Thanks, that's infinitely better :)

I'll try to reproduce & debug locally!

More accurate title.

Note that I probably won't have time for this until after RC1.

I am also getting this same error. At a minimum I am trying to integrate the optional CodeSnippet module from CKEditor into D8 CKEditor following examples from DrupalImage plugin. I can see the button on the plugin list (also with xdebug) and I can assign it to the active toolbar. However, reloading the page gives me:

"Uncaught TypeError: Cannot read property 'icons' of null"

Everything I have done looks nearly the same as what was done in core to register and display those plugins, yet no dice. The form settings and options are displayed and saved correctly to config, but the Javascript error prevents it from working. Not sure how to rectify this error.

I've put my code into a GitHub repository - I have debugged this as many ways as I can find and the same error persists.

https://github.com/kevinquillen/codesnippet

I have seen other modules work successfully, so I don't understand what is generating this error.

Examples:

• https://github.com/wwalc/panelbutton
• https://github.com/wwalc/colorbutton
• http://alexcoder.info/en/content/dobavlenie-plagina-ckeditor-v-drupal-8

Granted they are older..

The error appears to be thrown here in ckeditor.js:

for ( var pluginName in plugins ) {
	var plugin = plugins[ pluginName ],
		requires = plugin && plugin.requires;

	if ( !initialized[ pluginName ] ) {
		// Register all icons eventually defined by this plugin.
		if ( plugin.icons ) {
			var icons = plugin.icons.split( ',' );
			for ( var ic = icons.length; ic--; ) {
				CKEDITOR.skin.addIcon( icons[ ic ],
					plugin.path +
					'icons/' +
					( CKEDITOR.env.hidpi && plugin.hidpi ? 'hidpi/' : '' ) +
					icons[ ic ] +
					'.png' );
			}
		}
		initialized[ pluginName ] = 1;
	}

	if ( requires ) {
		// Trasnform it into an array, if it's not one.
		if ( requires.split )
			requires = requires.split( ',' );

		for ( var i = 0; i < requires.length; i++ ) {
			if ( !allPlugins[ requires[ i ] ] )
				requiredPlugins.push( requires[ i ] );
		}
	}
}

However 'icons' is defined in the codesnippet plugin definition - so it would seem that the plugin object here is either missing it or not defined correctly.

I can drag the icon from the toolbar into the active toolbar, and the settings form appears. I can save the form. But the reload of the page, the settings form isn't there, and dragging and dropping the button back on the toolbar makes it appear.

Okay, so this is interesting. I just updated to 8.0.0-rc3, in which updating the version of CKEditor occurred.

I no longer get this error:

"Uncaught TypeError: Cannot read property 'icons' of null"

But now, I get this new one:

"Uncaught TypeError: Cannot read property 'tagName' of null"

However, all plugins work, including my custom one - which wasn't before.

Several CKEditor fixes went in for RC3. One of them included updating CKEditor to version 4.5.4.

Can you please post the stacktrace? Just "Uncaught TypeError: Cannot read property 'tagName' of null" is pretty much useless. We need to know where that error is thrown. Thanks!

I found the same error and this is what I found (BTW,I am not sure if this should be its own issue).

It seems to be a problem with Drupal.behaviors.filterFilterHtmlUpdating._parseSetting whent trying to parse the <caption> tag, for some reason sandbox.firstChild returns null.

This is the stack trace

Uncaught TypeError: Cannot read property 'tagName' of null
    Drupal.behaviors.filterFilterHtmlUpdating._parseSetting @ filter.filter_html.admin.js?v=8.0.0:245
   (anonymous function) @ filter.filter_html.admin.js?v=8.0.0:76
   n.extend.each @ jquery.js:374
   n.fn.n.each @ jquery.js:139
   Drupal.behaviors.filterFilterHtmlUpdating.attach @ filter.filter_html.admin.js?v=8.0.0:73
   Drupal.attachBehaviors @ drupal.js?v=8.0.0:168
   (anonymous function) @ drupal.js?v=8.0.0:178
   n.addEventListener.t @ ready.min.js?v=1.0.8:4

Can you reproduce this with 8.0.1?

No, I cannot reproduce on a fresh install of 8.0.1

I'm on Drupal 8.0.4 and #15 seems to have resurfaced. If I add a CKEditor plugin and go to /admin/config/content/formats/manage/full_html I get a JS error.
Uncaught TypeError: Cannot read property 'tagName' of null
Same thing as #15 describes filter.filter_html.admin.js line 243.
sandbox.innerHTML = allowedTags[t];
When allowedTags[t] is "<caption>" innerHTML returns "" which makes node.tagName.toLowerCase() fail.

This is for now only affecting few people, so I won't have time for it soon probably. If you can work on a patch, this will get fixed much faster of course :)

The problem is that we are adding table tags e.g. caption, tbody, thead, tfoot, th, td, tr without a table. Here's a first pass at a patch.

Still getting this error on 8.4.x-dev and this patch fixes it.

ESlint complains about the latest patch:

core/modules/filter/filter.filter_html.admin.js
line 246	Expected '===' and instead saw '=='. (eqeqeq)
251	Strings must use singlequote. (quotes)

Fixing the ESLint issues. And being an ugly bug, it should go in 8.3.x.

Thanks! Re-RTBCing per #24.

Looks unrelated?

Steps to reproduce in the issue summary would be great. Should this have a test or is that overkill?

Only criticals are going into 8.3.x so bumping up to 8.5.x and this could potentially be backported to 8.4.x. Looks like this patch needs to be reworked for ES6.

@claudiu.cristea #26
Thank you. That fixed this error.

It's a bugfix so 8.4.x is still a valid target for this. This needs to be rerolled, it conflicts with the coding standards fixes that were done in #2880007: Auto-fix ESLint errors and warnings.

It was actually the change to ES6 that caused the conflict. Rerolled it, my first time working with ES6 :)

I wasn't able to generate an interdiff since it was faster to apply the changes manually rather than rebase on the pre-ES6 code base, but the one line that I changed was this:

-      var currentTag;
+      let currentTag;

And moved the code to the ES6 file + regenerated the fallback JS.

I have tried the patch #38 and it solved my problem.

Looks like we have missing test coverage. In order to commit a bug fix we need an automated to test to prove that we've fixed the bug and ensure that we don't break it again in the future. For more information about writing tests in Drupal 8 see the following links:

1. https://www.drupal.org/docs/8/testing
2. https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.5.x

+1 for #38

Here's the 'test only" patch.

The full patch. The interdiff is the patch from #44.

Manually tested that the fix works. Test looks okay to me too.

Can we get a review from the subsystem maintainers for the approach taken here?

Can we get this in?

I can confirm that this is still an issue as of 8.7.3 and that #46 works for 8.7.3. The patch addresses the problem for the following tags: caption, tbody, thead, tfoot, th, td, and tr. However functionality is still broken for the following table-related tags: colgroup, col.

I can confirm same for drupal/core (8.7.7) and #46.

Passed the .es5.js file to Prettier and fixed the test.

This is marked as "Needs subsystem maintainer review" since October 2018, I'll assign to @Wim Leers for a feedback.

Changes made look good, just formatting fixes and adding the admin theme. Still needs maintainer review, so not setting to RTBC.

I first created a duplicate Issue because I couldn't find this one (https://www.drupal.org/project/drupal/issues/3173615) but I can confirm, that the Patch from #56 fixed my problem!

Here's a re-roll of the patch from #56 against Drupal core 9.1.x.

Apologies for the long, long silence on this issue!

Special thanks to @claudiu.cristea for getting this issue back on track and completely overhauling the issue summary in #46 🙏

Test coverage looks great 👍

I'm wondering if the issue summary is correct because I could reproduce the problem even when

Tested patch in #62 on Drupal 9.1.5, it works and solves the issue.

Added MR and set to needs review - the test failure that switched this to needs work was intentional.

Updated the issue summary to make it clear that configured allowed tags are not the issue, but appending elements to a <div> that semantically can't have a <div> as its immediate parent.

The solution in #62 will fail if the configured tags have attributes. It only works if the tag and nothing else is provided, which defeats the purpose as the purpose of that code is to extract the tag name from an item with attributes.

I changed this to use a jQuery solution, which despite jQuery's reputation seems to be the most effective way to do it. A jQuery object can accept an argument of a tag with attributes, and doesn't need a parent element. Once created, the tag name can be parsed easily.

I agree that jQuery is a good solution here. It's purpose is to make life easier in those type of situations.

Code in the MR fixes the problem, there is a test, and a comment to explain why jquery is used.

The point in #65 about allowing table element when table is not allowed makes sense, follow-up feature request though :)

Committed 88498c7 and pushed to 9.3.x. Thanks!

Leaving open for potential backport to 9.2.x.

Posting patch to run tests against 9.2.x

Backported to 9.2.x based on @xjm, @effulgentsia, and @alexpott providing +1 for the backport on Slack.