[wp-trac] [WordPress Trac] #45341: WSOD when editing a page (Issue introduced between v5Beta3 and v5Beta4)
WordPress Trac
noreply at wordpress.org
Mon Dec 3 21:43:50 UTC 2018
#45341: WSOD when editing a page (Issue introduced between v5Beta3 and v5Beta4)
--------------------------------------+------------------------------
Reporter: timhibberd | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Editor | Version: 5.0
Severity: critical | Resolution:
Keywords: needs-patch dev-feedback | Focuses:
--------------------------------------+------------------------------
Comment (by timhibberd):
Cheers @mcsf for your follow-up in the [Nov 30 WP5.0 Status
report](https://make.wordpress.org/core/2018/11/30/5-0-gutenberg-status-
update-nov-30/) regarding this issue. Your assistance is much appreciated.
I have included your comment below for the purposes of further discussion
and to keep you in the loop:
--------------------------------------
''"To be clear, I am assuming we are talking about 45341 (cc @jorbin).
I’ve had a look at this and have discussed it with @aduth, and so far the
evidence suggests a server issue. Whatever is behind that, I believe the
central issue is that the JS assets are failing to properly load. In any
case, nothing indicates an issue of concurrency or in the way React
operates — rather, the failure to load critical packages leads to errors
in the initialisation of the editor. Furthermore, there don’t seem to be
corroborations of the actual WSOD, only of the logging of PHP notices.
In short: it was wrong to leave the ticket in the awaiting review queue,
but it’s not a critical bug. However, I hope we can spend some more time
to get to the bottom of it."''
--------------------------------------
I am still working through the request from @aduth to test the server
angle.
Although @aduth suggestion that the server may be timing out and returning
an incomplete Javascript file is a good suggestion and I will look to see
if that is the cause, it is however equally likely that the issue is a
REACT race-condition (browser side dynamic loading / rendering issue) or
an error on the server side in the dynamic production of the returned
JavaScript files.
Analysis Factors To Date:
- I had no fatal JavaScript errors in any WP5 release up to and including
v5Beta3 with this installation. The issues started to happen once I
upgraded to v5Beta4 and the issues have persisted in newer releases.
Anything interesting / significant in the REACT / WebPack arena between
v5Beta3 and v5Beta4?
- There are no failed file requests in the browser network log on any of
the pages with JavaScript errors so server delivery does not appear to be
an issue (this is a standard Turnkey Linux LAMP environment I have been
using for years with no server delivery issues)
- Some edit pages reproducibly succeed / fail simply by toggling the
browser (firefox) debugger on / off. Although this may change the request
dynamics to the server subtly it indicates a potential Javascript issue on
the browser rendering side more so than it indicates a server delivery
issue.
- It is unlikely to be a server delivery / network corruption issue
because a successfully rendered edit page is consistently rendered without
error through multiple refreshes then fails reproducibly with multiple
refreshes simply by toggling the browser debugger on.
- JavaScript errors are mid-file...this is not file truncation as one
would expect to see if there was a server error (see sample below)
Sample error with associated Javascript file:
{{{
06:54:14.337 SyntaxError: function statement requires a name[Learn More]
components.js:23645:9
06:54:14.420 SyntaxError: unexpected token: string literal[Learn More]
editor.js:19352:19
06:54:14.440 TypeError: external_this_wp_components_ is undefined[Learn
More] block-library.js:1515:5
06:54:14.453 TypeError: external_this_wp_components_ is undefined[Learn
More] edit-post.js:1113:5
06:54:14.459 TypeError: external_this_wp_components_ is undefined[Learn
More] format-library.js:1162:34
06:54:14.552 TypeError: wp.editPost is undefined[Learn More]
post.php:1729:4
}}}
{{{
var block_list_BlockList =
/*#__PURE__*/
function (_Component) {
Object(inherits["a" /* default */])(BlockList, _Component);
function BlockList(props) {
var _this;
Object(classCallCheck["a" /* default */])(this, BlockList);
_this = Object(possibleConstructorReturn["a" /* default */])(this,
Object(getPrototypeOf["a" /* default */])(BlockList).call(this, props));
_this.onSelectionStart =
_this.onSelectionStart.bind(Object(assertThisInitialized["a" /* default
*/])(Object(assertThisInitialized["a" /* default */])(_this)));
_this.onSelectionEnd =
_this.onSelectionEnd.bind(Object(assertThisInitialized["a" /* default
*/])(Object(assertThisInitialized["a" /* default */])(_this)));
_this.setBlockRef =
_this.setBlockRef.bind(Object(assertThisInitialized["a" /* default
*/])(Object(assertThisInitialized["a" /* default */])(_this)));
_this.setLastClientY =
_this.setLastClientY.bind(Object(assertThisInitialized["a" /* default
*/])(Object(assertThisInitialized["a" /* default */])(_this)));
_this.onPointerMove =
Object(external_lodash_["throttle"])(_this.onPointerMove.bind(Object(assertThisInitialized["a"
/* default */])(Object(assertThisInitialized["a" /* default */])(_this))),
100); // Browser does not fire `*move` event when the pointer position
changes
// relative to the document, so fire it with the last known position.
_this.onScroll = function () {
return _this.onPointerMove({
clientY: _this.lastClientY
});
};
_this.lastClie "componentDidMount",
value: function componentDidMount() {
window.addEventListener('mousemove', this.setLastClientY);
}
}, {
key: "componentWillUnmount",
value: function componentWillUnmount() {
window.removeEventListener('mousemove', this.setLastClientY);
}
}, {
key: "setLastClientY",
value: function setLastClientY(_ref) {
var clientY = _ref.clientY;
this.lastClientY = clientY;
}
}, {
key: "setBlockRef",
value: function setBlockRef(node, clientId) {
if (node === null) {
delete this.nodes[clientId];
} else {
this.nodes = Object(objectSpread["a" /* default */])({},
this.nodes, Object(defineProperty["a" /* default */])({}, clientId,
node));
}
}
/**
* Handles a pointer move event to update the extent of the current
cursor
* multi-selection.
*
* @param {MouseEvent} event A mousemove event object.
*
* @return {void}
*/
}, {
}}}
You can see the mid-file code line (editor.js:19352:19) {{{_this.lastClie
"componentDidMount",}}} appears to have been partially rendered. This
would be more of an indicator of a browser side dynamic loading /
rendering issue or a server-side file creation issue rather than a
delivery issue.
Or...it is possible that this WordPress / Server combo got corrupted
during the upgrade process from v5Beta3 to v5Beta4 and this is just a bad
build.
So...next steps...I am trying to re-create another Docker container from
scratch that reproducibly experiences these types of errors. If I can
reproducibly re-create an environment that reproduces these issues then
others can try to replicate. If I can't reproduce the environment I will
probably close this issue and we will roll the dice and hope that it was
just a bad build.
But it is worth some effort...race condition issues are a bugger in the
field and reproducing them in the lab in many cases is impossible. If this
IS a race condition issue then this build is worth its weight in gold.
I have some client work to do over today and tomorrow so I probably won't
get a chance to progress this further until the weekend. Given the push to
get V5.0 released I am trying to give this as much priority as I can
(debugging this type of issue is very time-consuming).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/45341#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list