High CPU usage on seemingly-idle dashboard page

I am using Firefox.

When sitting on a seemingly-idle dashboard page (just the "work" tab showing the various documents), I am seeing Prismic take up 100% of a CPU core, and this doesn't seem to have any end.

If I unload the page, CPU usage falls to near zero. Open it up again and it rises to 100% again.

If I open the debugger and pause execution, it almost always lands in one particular spot:

I wonder if this is a bug. Using this much CPU for no discernable reason certainly seems like one.

Hi Bart,

I've tried to reproduce the issue, but with no success:

Maybe you can share with us (in a private message) your account email address so that we try to reproduce the issue on our side?

Note: have you tried another machine?

Looking forward to your reply,

I did say Firefox and you're clearly testing in Chrome.

But I can reproduce in Chrome too.

I found that it does not happen with a less-tall window. It only occurs with a tall viewport. I believe it is probably related to "Infinite scroll" does not trigger on tall displays -- likely a busy loop caused by the same bug or a related one. Hopefully it'll be fixed once your new code rolls out.

I took a video demonstrating. It shows a few Chrome processes taking negligible CPU when the windows are above and below, but when I switch to side by side so they're taller, and go to the document list again, I see a full core's worth of CPU usage split between a few Chrome processes.

But I can't upload it to this because it's bigger than 4M.

1 Like

Thanks, @bart for your clarifications, I will try to reproduce and will get back to you.

I've done some test, and I can't reproduce the issue; here a video recording of my test

I'm using a 4k screen for my test, please let me know if I'm missing something in my test.
Screenshot 2021-04-20 at 20.33.40

Hi @bart, I have discussed this issue with @samlittlefair, and this issue can be related to the bulk actions feature. Did you have the bulk actions feature activated for your repository?

Note: I will do another test today with the documents list and not the repository list in a 4K display with lots of docs to be able to have the scroll activated.

It will also need your repository name to check if the bulk action feature is activated for you.


I emailed you my video.

I don't know what bulk actions is.

In your video you're not looking at a problem page.

  • You need a document listing page.
  • It has to have enough documents that there is more than one page.
  • The viewport needs to be tall enough that you can see the whole first page, and so it's claiming to be loading the second page but isn't really.
  • 4K screen will not be tall enough if you are doubling your pixels, since eg on a Macbook it's pretending to only really be 1080 pixels tall. I do not double my pixels. You might be able to simulate it by zooming out, or by using responsive design mode and making a super tall viewport. My viewport is around 2000 pixels tall.
1 Like

Hi @bart

I havn't been able to reproduce the issue (have a look at the following screen recording),

Bulk actions I've mentioned is a Beta feature to allow users to do modifications to documents in a bulk manner.
Can you share in a private message your repository name to check if it is on this Beta feature?

For that, I will create an issue in our tracker, and we will let you know in case of any updates.

See above where I mentioned that my viewport is around 2000 pixels tall. That's CSS pixels, not physical pixels. It has to be a minimum of about 1533 CSS pixels tall.

Your window isn't anywhere near tall enough to see the bug. If you don't have a display tall enough you can use the responsive design mode in your browser's dev tools to get a taller viewport. Make it 2000 CSS pixels tall, then refresh the page.

If it is tall enough, you will see exactly 20 items, and you'll see the "loading" animation at the bottom. No more items are loading; this is the other bug I keep mentioning. Meanwhile the window will be pinning a CPU at 100%.

...I take that back, your viewport does look tall enough -- sorry. What tricked me is that there are immediately more items than can fit in the viewport, and your "infinite scroll" load-more logic is working.

But when you switch to another page and back you already have 23 or more items visible in the list, which suggests you're perhaps using a newer version of the dashboard which loads more items immediately.

When I load the page, it loads only 20 items. As I keep mentioning, in the situation where I can see all of the initial items already, the load more logic is broken and the CPU gets pinned.

1 Like

There are still no updates on this issue; we will let you know in case of any updates.

1 Like

This thread is being monitored as an open ticket in the issue tracker. We will update this post as we get more information. If you have a similar use-case, you can β€˜Flag’ this topic to reopen.