-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Gutenlypso: update calypso classic block to update block content even if the editor instance is marked for removal #29858
Conversation
Test live: https://calypso.live/?branch=fix/more-tag |
Okay this is all set for review. @jsnajdr it looks like icfy might need some 👀 seeing a |
@gwwar ICFY got fixed, the Circle CI task restarted and now this PR is all green. |
Thanks @jsnajdr ! |
This PR should also fix #29833 |
I noticed a weird behavior after converting a classic block to blocks: if we insert new classic blocks, their content is not published. These are the steps I follow for reproducing the issue:
|
Oh super weird, the first blur excludes the content in the update, but the second one works. 🤔 Ah so I think I can reduce steps.
Nice catch |
😭 alright I think I have most major cases. Note that when we go into "Edit as html" we're using the editor package's component |
Thanks @mmtr I'll maybe timebox debugging for that case, as adding content without blurring > convert to blocks works in visual mode. We can file a follow up issue if I'm unable to get it today. |
🤔 @mmtr are there more steps? I think I reproduced once, but now I'm not having luck. Is this pretty consistent for you? |
Uhm... strange. I cannot reproduce it now neither. But those were the only steps I followed. In fact, I recorded a couple more GIFs before that one, and I always did the same, so I don't know what can cause that state. Will apply again the whole testing instructions and see if I detect how to reproduce it. Otherwise I think this is good to go. |
Same, I cannot reproduce it again, so I don't know what I did differently before. I guess we can ignore that since it should be a very corner case. |
… if the editor instance is marked for removal
…ce bookmark command
Got a clean run locally for the invites, and edit post suite.
|
I think I'm in the clear for the full e2e suite, I'll try landing and will revert if we note new breakages in master |
Changes proposed in this Pull Request
I don't really understand why the timing of the tinymce lifecycle events are lining up this way, but once we reach handlers like the ones that manipulate the more tag, the editor is already marked for removal, and so any content manipulation is not reflected.
In this PR I explicitly detect for this case, then update block content. I've also modified some behavior to more closely match the core Classic block. Basically we don't bother to update block content until on block blur rather than a debounced onchange event.
In the case of the more tag, we should see a nice visual placeholder in the visual mode, and an html more comment in the html view.
Before:

After:

Testing instructions
Publishing with a more block renders correctly
Visually toggling between visual/html shows the correct view
Converting to Blocks works
Content is saved when we focus out of the Classic block
This matches behavior in the core classic block.
Fixes #29643