Does not work

We investigated this thoroughly and found two separate bugs. Both are now fixed in latest release (1.0.2).

Bug 1 — Module appeared to "do nothing" (silent failure when full_html is missing)

The module's core logic (hook_canvas_storable_prop_shape_alter) was always architecturally correct. On a site with the
full_html text format already configured, it correctly intercepts all contentMediaType: text/html Canvas props and
replaces the restricted canvas_html_block / canvas_html_inline formats with full_html. Canvas then stores the updated
prop shape in its discovery cache, and any new component instance dragged onto a page picks up the full editor.

The problem: If full_html doesn't exist on the site, the hook exited silently with no feedback — no error, no log
entry, nothing. The only signal was a REQUIREMENT_ERROR buried on the Status Report page (/admin/reports/status). This
made the module appear completely broken when tested on a fresh minimal profile install or on Drupal CMS (which don't
ship a full_html format by default).

The fix: hook_install() now checks for full_html and immediately shows a visible admin warning if it's absent, telling
the user exactly what's needed:

Canvas Full HTML: The "full_html" text format was not found.
The module will not function until you create a text format
with machine name "full_html".

---
Bug 2 — Could not uninstall without deleting the Page

When Canvas discovers the rich_text_block SDC component provided by this module, it auto-generates a config entity:
canvas.component.sdc.canvas_full_html.rich_text_block. That config entity carries a dependencies.module:
[canvas_full_html] declaration. During uninstall, Drupal's config system tries to cascade-delete that config entity —
but if any Canvas page has ever used the rich_text_block component, the page entity holds a dependency on it, blocking
the deletion and therefore blocking the entire uninstall. Even after removing the component from the page layout in
the Canvas editor, the page entity's stored config dependency wasn't cleared, so the block remained.

The fix: hook_module_preuninstall() now deletes the generated component config entity before Drupal's dependency check
runs:

function canvas_full_html_module_preuninstall(string $module): void {
if ($module !== 'canvas_full_html') {
return;
}
$config = \Drupal::configFactory()->getEditable(
'canvas.component.sdc.canvas_full_html.rich_text_block'
);
if (!$config->isNew()) {
$config->delete();
}
}

Verified: We tested the full uninstall flow on a live site with an active Canvas page. The module now uninstalls
cleanly with drush pmu canvas_full_html — the page is left completely intact, and the component config entity is
removed automatically.

---
Environment tested

- Drupal 11.x, Canvas 1.2.0, canvas_full_html 1.0.1 (with fixes applied)
- full_html format present: module works correctly, drag any text/html prop component → full CKEditor 5 toolbar ✓
- Uninstall with an active Canvas page using the component: uninstalls cleanly, page survives ✓
- Re-install after uninstall: component config regenerated, hook active again ✓

Canvas Full HTML now has its own dedicated text format with full contrib plugin support

The module has been updated to use its own dedicated canvas_full_html text format (previously it reused the site's
generic full_html format). This gives the Canvas editor an isolated, purpose-built text format that can be configured
independently from other text formats on the site.

What's new:

- A dedicated canvas_full_html text format is now provided by the module, with filter_html disabled to allow
unrestricted HTML output in Canvas components.
- The module now pre-loads all CKEditor5 plugin libraries required by the canvas_full_html editor on Canvas pages via
hook_library_info_alter. This resolves a race condition where Canvas's React component (DrupalFormattedTextArea)
called selectPlugins() before contrib plugin DLL chunks had finished loading, causing the WYSIWYG field to silently
disappear.
- The following contrib plugins are now fully supported inside the Canvas editor: ckeditor5_plugin_pack (font color,
font background color, font size, font family, emoji, content templates), ui_icons_ckeditor5 (icon picker), and any
other CKEditor5 contrib plugin — as long as its Drupal library is registered and the plugin is enabled on the
canvas_full_html editor.

Root cause of the previous bug:

Canvas loads component forms via AJAX into a React component. When a text/html field was present,
DrupalFormattedTextArea.tsx called selectPlugins() which resolves each plugin from window.CKEditor5[build][name].
Contrib plugin DLL chunks (e.g. font.js, emoji.js) are loaded lazily by Drupal's normal text_format rendering pipeline
— but on Canvas pages that pipeline never runs for the initial page load. The chunks arrived asynchronously after
React had already attempted to initialize CKEditor5, so selectPlugins() returned null for any contrib plugin, causing
CKEditor5 to throw and the field to disappear entirely.

The fix:

By hooking into hook_library_info_alter for the canvas_full_html extension and calling
CKEditor5PluginManager::getEnabledLibraries($editor), we dynamically add all enabled plugin libraries as dependencies
of canvas_full_html/ckeditor-fixes. Since ckeditor-fixes is already a dependency of canvas/canvas-ui, all plugin DLL
chunks are guaranteed to be loaded on the initial Canvas page — before any AJAX component forms render.

I have to agree with the OP, as I can't get this module working either. I'm using Drupal Canvas 1.2.0 and version 1.0.4 of Canvas Full HTML.

Some issues I noticed:

1. After installing, and opening a Canvas page (but before adding/editing any components) I see the following error.

Ignoring this error and trying to place component that includes a rich text editor results in another error:

2. When I uninstall the module and try to reinstall, I get the following error:

Configuration objects (editor.editor.canvas_full_html, filter.format.canvas_full_html) provided by canvas_full_html already exist in active configuration

3. This is more of a feature request, but I'd rather have the choice of using a limited CKEditor text format vs. a full_html text format on a per component basis. The way it is now (all-or-nothing) seems not-as-useful to me.

-mike

@mike thanks for the review

Reinstall error — The filter.format.canvas_full_html and editor.editor.canvas_full_html config objects were missing dependencies.enforced.module: [canvas_full_html], so Drupal never cleaned them up on uninstall. Added enforced dependencies so both config objects are properly deleted on uninstall and recreated fresh on reinstall.

JS errors on Canvas pages — The ckeditor5/internal.drupal.ckeditor5 library was being loaded as a dependency of canvas/canvas-ui to preload CKEditor5 plugins. However, that library depends on core/drupal.ajax and Drupal's editor behavior system, which conflicts with Canvas's own custom AJAX handling. This was causing the e is not a function error on page load and the Drupal.ajax is undefined error when placing a rich text component. The fix keeps only the actual CKEditor5 plugin DLL chunk libraries (core/ckeditor5.*) as pre-loaded dependencies — those are the ones actually needed to prevent the selectPlugins() race condition — and excludes the Drupal integration library that was causing the conflicts.

Please test with 1.0.5 and let us know if the issues are resolved.

Attached the screenshot with Drupal 11.3.2 also with Drupal CMS 2.0 it loads the editor perfectly in both Drupal setups
And this module now uses its dedicated text format canvas_full_html so you can modify it as per your need
But Canvas doesn't let us choose text filters in components that why that feature is still pending (your last point).

I did not find any errors on canvas pages after uninstalling and reinstalling.

I followed these steps:

1. Installed the module and confirmed that it was applied in the text editor of the Canvas SDC component.
2. Made changes to the content using the Full HTML text editor and saved the page.
3. Uninstalled the module, cleared the cache, and observed that:
   • No errors occurred
   • The changes remained in the SDC component
4. Reinstalled the module and cleared the cache again, but still did not encounter any errors, as shown in the screenshot shared in previous comments.

@ultimike This happens because JavaScript file aggregation is enabled by default under admin/config/development/performance. When you disable this setting, the error message disappears.