Widget screen blank with 5.8

[laurelfulford]

When running the WP 5.8 beta (currently beta 4) and the Newspack theme, if you navigate to WP Admin > Appearance > Widgets, the screen is blank.

This doesn't happen with a default theme; when you view the console you get the following errors:

data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3351 An error occurred while running 'mapSelect': Cannot read property 'getCurrentPostType' of null
useSelect @ data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3351
post-meta-toggles.js:91 Uncaught TypeError: Cannot read property 'editPost' of null
    at mapDispatchToProps (post-meta-toggles.js:91)
    at Object.mapDispatch [as current] (data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3632)
    at data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3524
    at mountMemo (react-dom.js?ver=16.13.1:15577)
    at Object.useMemo (react-dom.js?ver=16.13.1:15873)
    at useMemo (react.js?ver=16.13.1:1607)
    at useDispatchWithMap (data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3523)
    at data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3634
    at renderWithHooks (react-dom.js?ver=16.13.1:14938)
    at mountIndeterminateComponent (react-dom.js?ver=16.13.1:17617)
react-dom.js?ver=16.13.1:19662 The above error occurred in the <WithDispatch(PostStatusExtensions)> component:
    in WithDispatch(PostStatusExtensions)
    in Unknown (created by WithSelect(WithDispatch(PostStatusExtensions)))
    in WithSelect(WithDispatch(PostStatusExtensions)) (created by plugin_area_PluginArea)
    in div (created by plugin_area_PluginArea)
    in plugin_area_PluginArea (created by Layout)
    in BlockRefsProvider (created by BlockEditorProvider)
    in BlockEditorProvider
    in Unknown (created by Context.Consumer)
    in WithRegistryProvider(BlockEditorProvider) (created by WidgetAreasBlockEditorProvider)
    in slot_fill_provider_SlotFillProvider (created by Provider)
    in provider_SlotFillProvider (created by Provider)
    in Provider (created by WidgetAreasBlockEditorProvider)
    in WidgetAreasBlockEditorProvider (created by Layout)
    in Layout

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://fb.me/react-error-boundaries to learn more about error boundaries.
logCapturedError @ react-dom.js?ver=16.13.1:19662
react-dom.js?ver=16.13.1:22800 Uncaught TypeError: Cannot read property 'editPost' of null
    at mapDispatchToProps (post-meta-toggles.js:91)
    at Object.mapDispatch [as current] (data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3632)
    at data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3524
    at mountMemo (react-dom.js?ver=16.13.1:15577)
    at Object.useMemo (react-dom.js?ver=16.13.1:15873)
    at useMemo (react.js?ver=16.13.1:1607)
    at useDispatchWithMap (data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3523)
    at data.js?ver=7bfa3a673439e85e459d5ec92d30fdda:3634
    at renderWithHooks (react-dom.js?ver=16.13.1:14938)
    at mountIndeterminateComponent (react-dom.js?ver=16.13.1:17617)

Commenting out where newspack-post-meta-toggles is enqueued makes the error go away.

It looks like this is related to scripts added with enqueue_block_editor_assets being included on this screen so the blocks will work as expected, and us using that to enqueue the newspack-post-meta-toggles, which then tries to figure out the post type before doing anything (which seems to be where things fall apart).

[laurelfulford]

Also noting if the above can be resolved (which I'm doing probably incorrectly in a test branch right now), this error that's related to the AMP fallback JavaScript is thrown:

Uncaught TypeError: headerContain is null
    <anonymous> webpack:///./newspack-theme/js/src/amp-fallback.js?:38
    <anonymous> webpack:///./newspack-theme/js/src/amp-fallback.js?:208
    js http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:96
    __webpack_require__ http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:20
    <anonymous> http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:84
    <anonymous> http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:87
amp-fallback.js:38:26
    <anonymous> webpack:///./newspack-theme/js/src/amp-fallback.js?:38
    <anonymous> webpack:///./newspack-theme/js/src/amp-fallback.js?:208
    js http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:96
    __webpack_require__ http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:20
    <anonymous> http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:84
    <anonymous> http://one.wordpress.test/wp-content/themes/newspack-theme/js/dist/amp-fallback.js?ver=1.0.0-alpha.33:87

Best I can tell some widget previews create iframes that pull in front-end code (including the AMP fallback JS):

Adding a check if headerContain exists should resolve.

[matticbot]

🎉 This issue has been resolved in version 1.39.3-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This issue has been resolved in version 1.39.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀