Error with "postLockUtils undefined"

[lotharthesavior]

Describe the bug

After updating to the latest version of gutenberg I started to have a problem with a "white screen" at th block editor when the second user opens a document that is being edited. The error is postLockUtils is undefined. This is the error being thrown with the npm run dev mode:

To Reproduce

Steps to reproduce the behavior:

1. Open a document
2. Open an incognito window and login with a different user
3. Open the same document (marked as being edited by another user)
4. You will get the white screen of death (the console shows this: postLockUtils is undefined)

Expected behavior

The system should show the expected modal asking the user between take over the Post edition or go back to post list.

Screenshots

Desktop (please complete the following information):

• OS: maOS Mojave 10.14.13
• Browsers: Firefox (65.0.1 (64-bit)), Firefox Developer Edition (66.0b10 (64-bit)), Chrome (72.0.3626.119 (Official Build) (64-bit))
• Version: mentioned following the browsers names.

Smartphone (please complete the following information):
...

Additional context

• Updated with the commit 1ed9995 (from Feb 27 4am EST)

[lotharthesavior]

I noticed that if I, just for testing, take out the <PostLockedModal /> at the file gutenberg/packages/edit-post/src/editor.js:69, and build again, it opens the block editor with the post without the blocker functionality. I would say that there is a missing prop in this call?

I'm saying this because I saw this: const { autosave, updatePostLock } = this.props; at the file gutenberg/packages/editor/src/components/post-locked-modal/index.js:89

[youknowriad]

Is this happening on master? Can you test in this branch #14082 it can have an impact there?

[lotharthesavior]

Thanks for your comment here, I'll test in a few moments. I saw earlier that this call might not be the last "invocation" of that object, since it also goes through an action... Because of that, It might be due to a missing dependency. I'll check this branch and let you know.

[lotharthesavior]

@youknowriad indeed, with that branch the problem doesn't happen, do you know what might be causing this?

[youknowriad]

I have an idea yes, recently we changed the editor settings location and they might be initialized a little bit too late in master causing this issue. In this PR, the settings are restored to their previous location.

[lotharthesavior]

Am I suppose to consider this ticket solved by that PR?

[youknowriad]

yes, when it's merged :)