Calypso/Editor: Freeze almost immediately after loading a page

[deBhal]

A user has reported that opening a moderately long page in the Calypso editor results in the page freezing for long enough to trigger the Wait/Kill dialog.

I was able to reproduce by SU-ing in and opening the page in the editor. The page loads promptly, but almost imediately afterwards the page locks up for a long time, maybe 30-40 seconds and the user reports 60-90 on slower hardware.

Steps to reproduce

1. Private user data makes it inappropriate to add much more detail here, but details about the specific site and page are in ticket 790919-zd-woothemes but the short version is:
2. Site Pages >
3. Try scrolling down the page, observe the long freeze

Browser / OS version

Chrome / Windows 10 & OSX 10.12.6

Context / Source

The user reports that they've been using this page at about this size for the last year, so it looks like this might be a performance regression. It also makes me wonder if the freeze might be related to the long history rather than the long page.

I'm not sure if it's a delay or the scrolling that triggers the freeze. The issue is somewhat intermittent, and I reloaded with an empty cache to get it to happen a second time, and then unsuccesfully tried to reproduce against a development build after that.

I ran performance profiling the second time, and confirmed that Calypso is spending all that time in scripts. After comparing the minimized code with an unminified version, I'm pretty confident it's spending the 90% of the time in clonePath() in diff.js

Related: #19446

[jeremeylduvall]

I've also been experiencing this for the past week at least when writing on my personal blog. My hangs are usually only 5-10 seconds though, but I can't do anything in the editor during that time.

[gpmw]

I just had a user report the same issue and I was able to reproduce it by SUing and it took about 10 seconds before I was able to edit.

[julsyd]

Another report of this on byronchristopher.org. I was able to see it when SSP'd. I can scroll through the post in the Calypso editor, but can't click on anything to actually edit it.

@designsimply More info:
The user reported this is happening when editing any post. I was able to see the same issue when editing post 8383 in Calypso.

The post has 12876 words. It opens and scrolls normally in Calypso, but clicking or typing within the post has no effect, so it's essentially frozen and uneditable. I can't even click the back button in Chrome. Eventually a non-responsive window pops up in Chrome.

Screencast: https://cloudup.com/caiff4lxkHU
Screenshot of JS console: https://cloudup.com/cLWaVZH2jEi

[keithlock75]

Feels like the same issue reported in ticket: 791821

Tried on: macbook pro mid 2012, running OS X 10.11.6, 2.9 GHX core i7, 8BG ddr3 ram, intel HD 4000 video card.

And: "chrome and edge on my windows pc"

User description - I can open the edit page and I see the first 3 paragraphs with info but when I scroll down, the ball starts to spin.

[carladoria]

A user reported this on chat 525800, however, I wasn't able to reproduce it. I'll be following the user to find out more details.

[msilbers]

User reported this in HC transcript 1026179. Only just started, no significant changes, happening when trying to add links to existing pages that are relatively long

[carladoria]

Another user reported this on HC chat 1026731. This time I was able to reproduce it.

[designsimply]

@deBhal, may I ask the word count and the number of revisions for the page you tested?

@jeremeylduvall, are you saying you've been experience the problem for shorter posts?

@gpmw, would you mind including the ticket or chat transcript number in comments on bugs? It's helpful if we need look at the reports in more detail later!

@juliasydnor, was that problem on byronchristopher.org happening on just a particular page or every page?

@keithlock75 thanks for including browser/OS details!

@msilbers that part about it only happening on pages that are relatively long is noteworthy. May I ask for a specific example of one of the pages such as the word count and number of revisions?

@carladoria did you happen to spot any error messages when you were able to reproduce the problem?

[jeremeylduvall]

@jeremeylduvall, are you saying you've been experience the problem for shorter posts?

Now that I'm trying to go back and record the darn thing I can't reproduce the issue 😂 I write a blog post every morning in Chrome. I would say I experience it more often than not. The posts are short, and I'm copying and pasting text from another site. The general steps are:

1. Visit site and copy text.
2. Open post editor directly by visiting wordpress.com/post
3. Paste in content into text editor
4. Try to start typing to add some additional text.

The editor hangs initially on step #4. If it happens tomorrow, I'll screencast it. (Chrome 61.0.3163.100)

[designsimply]

The posts are short

Hmm. Thanks for noting this.

If it happens tomorrow, I'll screencast it.

Thanks! Could you keep the console open as it runs in case any helpful js error pop up?

[carladoria]

@carladoria did you happen to spot any error messages when you were able to reproduce the problem? >

Yes, after some seconds I got the Wait/Kill dialog.

[designsimply]

I tested using Chrome 62 on Windows 10 with the following steps:

1. Go to https://www.lipsum.com/ and generate 10,000 words to use as sample text.
2. Go to Pages > Add.
3. Add a title and copy the sample text into the body.
4. Publish the post.
5. Go back to Pages.
6. Click on the new page and time how long it takes to open and become responsive.

Result: it took 1m17s after I loaded the page before I could interact with it.

Error seen in the console:

Uncaught (in promise) DOMException: The transaction was aborted so the request cannot be fulfilled.
/page/design5279.wordpress.com/11436:1
Promise rejected (async)
s.onabort.s.oneerror @build.9f955b5….ming.js:74

^{Seen at https://wordpress.com/page/design5279.wordpress.com/11436 (a page with 10,000+ words) using Chrome 62 on Windows 10.}

I also tested with pages containing 3,000 words and 7,000 words and those loaded without problems. The page with 10,000 words consistently took over 60s to load.

[supernovia]

We're seeing this here too:
https://loopbraider.files.wordpress.com/2017/11/unresponsivescriptshot.jpg

Another user complained they're getting it even with shorter posts.

[deBhal]

@designsimply: The example I was looking at is 3003 words, with 25 revisions.

While checking that, I noticed a similar freeze when I clicked on the "History" button, this time in a development environment where I could see where the code was running and get a proper stack trace:

That's 84 seconds spent here https://github.com/Automattic/wp-calypso/blob/master/client/state/data-layer/wpcom/posts/revisions/index.js#L77
processing the result of a POST_REVISIONS_REQUEST.

It's possible that this is a similar related problem and not the actual cause, but it lines up with what I've seen - the page loads, renders quickly while firing off the revision request, and then a moment later when it arrives everything freezes while it processes it. If it turns out to be a separate issue we can move it into a new issue.

@bperson: Given the performance conversation in #14241, it seems pretty plausible that this is coming from 9fa4f44

[msilbers]

@msilbers that part about it only happening on pages that are relatively long is noteworthy. May I ask for a specific example of one of the pages such as the word count and number of revisions?

I SUed in and got a wait/kill after at least 15 seconds on a page with 4092 words, 25 revisions.

[bperson]

I can't reproduce a freeze outside of clicking "History" ( and I don't see any revisions request going out ).

If I do click on "History" though - on posts with lots of words - I do experience a freeze coming from computing the diff, and I'm not sure there is a solution ( besides not computing the diff for large posts, only displaying the raw revisions? ).

Revisions got a pretty massive rewrite in #19197 Samus ( cc/ @jblz @marekhrabe @spen ) might know more about where they want this to move forward.

As a sidenote, 25 revisions is the maximum number of revisions we keep for a post on WP.com ( except a8c p2s and a couple of other exceptions ). Old revisions are deleted to make place for new ones and the API we use is not paginated which is also an extra edge case not really supported currently.

[deBhal]

Go to https://www.lipsum.com/ and generate 10,000 words to use as sample text.

Oddly, I generated a page like this and it does freeze up in production, but doesn't in a developer build.

I can't reproduce a freeze outside of clicking "History" ( and I don't see any revisions request going out ).

If we're not sending requesting the revisions when we load it then the history freeze might be a different issue, but you can sort of make out the code even minimized, and it did look like the same diff() loop at the heart of it, so I would think that they're very similar.

I'm not sure there is a solution

The killer for the user experience isn't so much the amount of work we need to do to get the diffs as the way we block the ui while we do it. If we could push it out into a web worker or break it up across promises it would just look slow, rather than broken.

Disabling the diff might be a solid quick-fix if we can target it and still diff smaller posts (Some function of word count & revisions maybe, or a time-out?).

[gemmagarner]

Another report in 883790-f. I've been able to reproduce the freezing on Chrome 62.0.3202.94 (OSX 10.12.6).

[KokkieH]

Had a report via Twitter for https://spacemargin.wordpress.com/. Happening on Pages over 20 000 words in length and with 25+ revisions.

As a sidenote, 25 revisions is the maximum number of revisions we keep for a post on WP.com

One of the pages I checked on this site is actually showing 26 revisions in WP-Admin.

[donalirl]

Another case in HC 1021724. Calypso page editor goes wait/kill on Chrome and Safari on Mac after a few seconds. I could reproduce in Chrome on Windows with SSP. There is a screencast in the user's Media folder.

[julsyd]

Another case in HC249823 / ZD791878 (wildwayroute24.com).

User sees the following error when editing any page in Firefox:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: https://wordpress.com/calypso/…ld.dc5324b687cf900c4b81.min.js:71

I was able to reproduce this when SSP'd and editing page ID 5 (3094 words) in Firefox.

[marekhrabe]

Problem identified in code that is translating revision objects from API to redux store. Fix incoming…

[gemmagarner]

Another report in 883760-f. Able to reproduce when I SU'd — I can scroll up and down the page but the editor buttons are unresponsive.

[dromero20]

Another report in 8183797-c. Tried with Firefox, Opera and Chrome, on Linux. Firefox and Opera on Windows 7 64bit. Also tried Firefox on Windows XP, different PC (same router).

[marekhrabe]

Bug is now fixed in production. If you want to follow up with users that reported the bug, that would be 💯.

Thanks everybody for great reports and investigations that lead us to the bug! :)