Chromium based browsers crash without warning

[ChrisLaRocque]

Describe the bug

When running a Slidev presentation in a chromium-based browser (I tried Arc and Chrome), the browser will close without warning after an indeterminate amount of time. When restarting Arc I get the "Arc quit unexpectedly" error with the ability to report, but Chrome provides no error. Safari appears to be working.

Minimal reproduction

Steps to reproduce the behavior:

1. Create a new Slidev project
2. Run slidev --open
3. Wait until the browser crashes (thus far hasn't taken longer than 20 minutes)

Environment

• Slidev version: 0.49.26
• Browser: Chrome Version 127.0.6533.120 (Official Build) (arm64)
• OS: Mac OSX 14.5

[equt]

Also on macOS 14.5 (23F79), Chromium based browser. After opened the localhost (start the connection), a process named runningboardd will immediately take up 100%+ CPU usage. It will be fine once disconnected.

---

@ChrisLaRocque I can confirm that after pinning the slidev cli version to 0.49.24 works. Will it also solve your problem? I guess it should be an upstream problem introduced in https://github.com/slidevjs/slidev/commit/72a9285eec820cd720f2a1925b21874846f05635.

[KermanX]

This seems to be a serious problem. However, I can't reproduce this on my Windows machine😭

I also think this is an upstream problem. Could you help check this by switching to the old dependencies via the overrides field in package.json?

[twitwi]

in the other issue reverting to 0.49.24 seems to be a workaround (using "0.49.24", , without any ^, in package.json, and pnpm install again)

[ras0q]

Not sure if this is benefical, but I override vueuse (@vueuse/core, @vueuse/math) versions from v11 to v10 and it seems stable after 30 minutes of startup.

relevant commit: https://github.com/slidevjs/slidev/commit/9a1e824eb78827f9a3a68029a809dd989ecd6a75

// package.json
// I'm using pnpm
{
  "pnpm": {
    "overrides": {
      "@vueuse/core": "10.11.1",
      "@vueuse/math": "10.11.1"
    }
  },
  "packageManager": "pnpm@9.7.1+sha512.faf344af2d6ca65c4c5c8c2224ea77a81a5e8859cbc4e06b1511ddce2f0151512431dd19e6aff31f2c6a8f5f2aced9bd2273e1fed7dd4de1868984059d2c4247"
}

[KermanX]

Not sure if this is benefical, but I override vueuse (@vueuse/core, @vueuse/math) versions from v11 to v10 and it seems stable after 30 minutes of startup.

relevant commit: 9a1e824

Thanks a lot for the information!

Does the issue still happen after setting wakeLock: false in headmatter?

I can confirm that this is caused by the wake lock. The minimal workaround should be setting wakeLock: false in the headmatter.

[KermanX]

A new version released. Hopefully, everything will be fine now.

Never use async inside watchEffect, especially when the async function is a DOM API 😭

[equt]

@KermanX Great thanks for the fix. Just out of curiosity, could you provide more details on why calling the localStorage API in watchEffect is not recommended?

[KermanX]

Just out of curiosity, could you provide more details on why calling the localStorage API in watchEffect is not recommended?

I checked the code again and found that the async DOM API (in this issue, avigator.wakeLock.request), is not the cause.

Usually, we are not afraid of updating a ref inside watchEffect. For example, watchEffect(() => { a.value++ }) will only run once when a is changed.

Even if there is an infinite loop like this example, the "Maximum recursive updates exceeded" error will be thrown by Vue - and then we can fix this immediately.

However, the infinite loop won't be detected after an async operation.

import { watchEffect, ref } from 'vue'

const a = ref(0)

function sleep(ms) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms)
  })
}

async function f() {
  a.value++
  await sleep(0)
  a.value++
}

const enabled = ref(true)

watchEffect(() => {
  if (!enabled.value)
    return
  console.log('run')
  f()
})

This is not quite unexpected - Vue can't know the context after await sleep(0). However, when f is provided by a 3rd-party library, it becomes hard to notice when writing the code.

[schauppi]

It´s working again with v0.49.27. Thx for the fast fix! :-)

[schauppi]

It´s working again with v0.49.27. Thx for the fast fix! :-)

Update: I used it for an hour now and the same bug again.

[KermanX]

Update: I used it for an hour now and the same bug again.

I can't reproduce in the new version 🤔

[twitwi]

I cannot reproduce either with 0.49.27 (I haven't tried for 30 minutes but it originally crashed right away)

[schauppi]

The problem continues even with version 0.49.27. I'm not sure why, but it worked for about 45 minutes before it stopped again, even after restarting the system.

[KermanX]

The problem continues even with version 0.49.27. I'm not sure why, but it worked for about 45 minutes before it stopped again, even after restarting the system.

Does the workaround in https://github.com/slidevjs/slidev/issues/1826#issuecomment-2299198069 still useful? And can you confirm the version you're running?

[schauppi]

I re-ran npm install @slidev/cli, and it seems to be working now! I'll do some more testing to confirm. I don't really know what's going on, haha.

[Boshen]

My chrome kept crashing after 5 minutes for the past two days while trying to record for my Vite conf talk 🥲

I'm on version 0.49.29, used QuickTime Player for screen recording with slide'v builtin camera mode (so heavy CPU and memory usage).

My final successful attempt was wakeLock: false.

There may be a correlation with lock screen time as well ...

---

I'm happy to help and triage further if you can tell me what to look for. I don't want the next person to have Chrome crashing 😅