-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Widget screens: set html block as freeform content handler #33164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Size Change: +45 B (0%) Total Size: 1.05 MB
ℹ️ View Unchanged
|
|
A-ha, it's the difference between using "cmd+c" and clicking "copy" in the context menu. Shouldn't the two behave the same though? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a well-thought and safe fix, just what we need at the RC stage – great job @getdave 👍 . Let's keep the parser discussion going in parallel.
On, and the e2e failures are the same as in trunk so I'd say this one is good to go.
draganescu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good catch @getdave

Description
This PR addresses a problem in the widgets screens whereby copy/pasting blocks would result in "missing" blocks being inserted into the editor canvas.
We do this by registering the
core/htmlblock as the default freeform content block to replace the defaultcore/freeformblock which we have de-registered for the Widgets screens to avoid allowing access to the Classic block interface.Explanation - why does this happen?
These missing blocks were generated by whitespace (inc. new lines) in between block definitions. For example:
The whitespace was being converted into the
core/missingblock due to thecore/freeformblock being de-registered in the Widgets editors. As thecore/freeformblock is set as the default freeform content handler this causes a bug.The reason for this was that the default block parser utilises the registered free form content handler to handle any random content (HTML) in between block definitions (including whitespace). As the free form content handler was de-registered the parser was falling back to the
core/missingblock - thus the errors on paste.For full info and context please see comments in #33097.
Also related: I have a proposal in #33136 to have the parser ignore and not try to create a freeform block for any content that is purely whitespace that it finds in between block definitions during parse.
Fixes #33097
How has this been tested?
core/missingblocks.Screenshots
Screen.Capture.on.2021-07-02.at.11-50-32.mov
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.jsfiles for terms that need renaming or removal).