There should be some way to globally disable the magic block feature

[oleq]

ATM it's a dependency of Widget so even config.removePlugins won't work and some integrators may want to get rid of it (for whatever the reason).

When we implement the keyboard support, then using CSS to get rid of it won't be an option because the feature will change the behavior of the selection.

[Reinmar]

I'm considering moving it to Essentials. It's fairly easy to replace Essentials with your own list of plugins. 

Alternatively/Optionally, we could introduce something like optional dependencies. You would be able to use config.removePlugins to remove an optional dependency. This could potentially be useful in more cases. WDYT?

I feel that using WidgetTypeAround#isEnabled in order to disable that feature as a whole makes no sense. It shows that we're doing something wrong.

OTOH, if WidgetTypeAround is an optional dependency of Widget, then its code will be included in the bundle even if you want to disable it, which still smells bad. Perhaps we should just move it to Essentials and that's it. Alternatively, Widget could become such a glue plugin (all code would need to be moved elsewhere, e.g. to WidgetEngine).

[oleq]

As for extending the Essentials: for one thing, I don't think the WTA is essential (like undo or enter). For another, it's a subset of some other feature (Widget) which itself is optional (you may not load image/media/table and not use Widget at all) so I see no good reason to elevate it.

Alternatively, Widget could become such a glue plugin (all code would need to be moved elsewhere, e.g. to WidgetEngine).

I like this feature composition concept so maybe this is the right thing to do.

[Reinmar]

Cases to address:

• Disable the entire feature (buttons, keyboard) cause someone may simply not like it at all.
  • The simplest option here will be to use WidgetTypeAround#forceDisabled().
• Hide buttons in all cases cause e.g. they obscure the view.
  • For now, CSS will be enough.
• Disable the ability to type before/after a certain widget instance (i.e. - caret and buttons).
  • It seems that it could be driven by view-element custom properties (for before and after the widget).

[Reinmar]

TODO: We need to write a feature guide or a deep dive guide in the framework section in which we'll:

• introduce and showcase this feature
• list the ways to disable it (all 3)

[jswiderski]

Use case from the client (support ticket no. 63880) - they want to block the behavior completely because they only want to allow typing inside widgets which makes perfect sense if they have one big widget inside editor a content area.