Describe the bug
Action addon took surprisingly long time to response (freeze the screen >4 sec).
To Reproduce
Steps to reproduce the behavior:
action addon function.An example from official-storybook: http://localhost:9011/?path=/story/basics-link--no-cancel-w-onclick
Expected behavior
A instantaneous response <150ms.
Screenshots

A bit profiling here, I'm render my story into standalone iFrame mode. This profiling shows the complicated string operation happened down to the message channel:

Code snippets
If applicable, add code samples to help explain your problem.
System:
Additional context
The component is a pure material-ui button. I thought my custom addons have some role on this but I still have faced this issue even I only have 1 story and no other addon at all...
Probably stringifying the event object? @ndelangen ?
Maybe not relevant, but it seems that channel can not broadcast Symbol object? (will have to check on the case in node side for sure...)
Indeed, I noticed this as well. Something is not right in the serialization, it used to work really fast :(
I added a link to one of our stories in the description
This is really a bug in telejson maybe? In any case I will leave it to you @ndelangen.
I'm on it
Fixed
Hurrah!! I just released https://github.com/storybooks/storybook/releases/tag/v5.0.0-rc.6 containing PR #5751 that references this issue. Upgrade today to try it out!
Because it's a pre-release you can find it on the @next NPM tag.
This issue is still apparent to us, even after upgrading the storybook to 5.1.9 .
Only adding depth: 3 fixes the problem, but that's a workaround, not a solution. As I've seen in https://github.com/storybookjs/storybook/issues/2590 , events shouldn't be serialized at all?
That's how it looks like for us:

Without the depth: 3, printing the event takes ~3-7s on my MacBook Air.
Probably because event.view is Window and window has an infinite recursion to itself (window.self === window).
Just chiming in to say that I'm experiencing this on 5.1.9 as well
Thanks @tw15egan. This was fixed in 5.2.0-alpha.36. I'll patch the fix into 5.1.10.
Awesome! Thanks for the quick response 馃憤
Mhm, FYI we had just had updated to 5.1.10 and the issue still persists.
@ndelangen #7256 went out in 5.1.10 but the perf issue remains. Any chance you can take a look?
Can confirm we'll still seeing a big performance hit
Still seeing this issue in 5.2.3
Most helpful comment
Awesome! Thanks for the quick response 馃憤