github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 19:47:47 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #125] Task editing UI continuously re-renders, causing high CPU usage and some UI issues #5976

New Issue
Closed
opened 2026-04-20 16:27:06 -05:00 by GiteaMirror · 11 comments
GiteaMirror commented 2026-04-20 16:27:06 -05:00
Owner
Copy Link

Originally created by @GottemHams on GitHub (Jan 10, 2024).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/125

Description

I'm not 100% sure if this is an issue with the Vikunja frontend itself or one of the frameworks it uses (I think it's Vue/Vite?), but it seems most appropriate to start here. I tried searching in all mentioned repositories for some parts of the JavaScript I've shown further below but nothing came up. The issue only seems to exist on Firefox and occurs even in safe mode (all addons disabled), although I've only tested with Chrome besides.

It looks like almost the entire UI is continuously being re-rendered when the edit task page is open, even without any interaction with any part of the UI. This happens regardless of the task UI being rendered in a modal (e.g. opening a task from the kanban view) or in its own separate page (e.g. from list view). Firefox's developer console highlights modified nodes with a yellow background, which as you can see are quite a lot of nodes.

The re-render happens fast enough that all those nodes are never not highlighted, which causes a major spike in CPU usage. When the task UI is in a modal and I close it, CPU usage immediately drops back down to sub 1% or even "idle", so it's not an issue with the page it was shown on.

It also causes some side effects with usability of the UI, particularly an opened select input which keeps resetting the selection to its current value (e.g. the task relation type input). This again happens very fast, it's nearly impossible to select the value you actually want. Unless you know exactly what you need and can use your keyboard to change the value while it has focus (but not opened). Here's a lil' screen recording. Text inputs seem unaffected at least.

Since even the document's root (<html>) is being modified, I decided to add a breakpoint on that tag for attribute modifications. It seems a certain attribute is continuously being added and removed, and due to the reactiveness of Vue/Vite it also re-renders a whole bunch of child components every time? First it showed me <html class="dark" q-has-scope5301926="" lang="en"> and 2 breakpoints later it becomes <html class="dark" q-has-scope5218981="" lang="en">. The JS code the debugger is breaking on:

var Be = 'q-has-scope' + (Math.floor(9000000 * Math.random()) + 1000000);
ze.setAttribute(Be, '');

// Then the breakpoint after that:
if (ze.removeAttribute(Be), Ve.length > 0) {

As I've mentioned in the starting paragraph: I tried searching for some key parts of this JS in Vue/Vite/Vikunja repos (hoping to find the unobfuscated source) and I couldn't find anything, hence why I'm not sure in what part of the chain this problem exists.

I created a new task on the demo site and I have the same issue there.

Vikunja Frontend Version

0.22.0

Vikunja API Version

0.22.0

Browser and version

Firefox ESR 115.6.0

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

Originally created by @GottemHams on GitHub (Jan 10, 2024). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/125 ### Description I'm not 100% sure if this is an issue with the Vikunja frontend itself or one of the frameworks it uses (I think it's Vue/Vite?), but it seems most appropriate to start here. I tried searching in all mentioned repositories for some parts of the JavaScript I've shown further below but nothing came up. The issue only seems to exist on Firefox and occurs even in safe mode (all addons disabled), although I've only tested with Chrome besides. It looks like almost the entire UI is continuously being re-rendered when the edit task page is open, even without any interaction with **any** part of the UI. This happens regardless of the task UI being rendered in a modal (e.g. opening a task from the kanban view) or in its own separate page (e.g. from list view). Firefox's developer console highlights modified nodes with a yellow background, which [as you can see are quite a lot of nodes](https://github.com/go-vikunja/frontend/assets/20195269/99f16dbe-8fb5-43ac-9ece-602db2a69707). The re-render happens fast enough that all those nodes are never **not** highlighted, which causes [a major spike in CPU usage](https://github.com/go-vikunja/frontend/assets/20195269/c4b32258-8227-4b8b-9ecc-75a37b699998). When the task UI is in a modal and I close it, CPU usage immediately drops back down to sub 1% or even "idle", so it's not an issue with the page it was shown on. It also causes some side effects with usability of the UI, particularly an opened `select` input which keeps resetting the selection to its current value (e.g. the task relation type input). This again happens very fast, it's nearly impossible to select the value you actually want. Unless you know exactly what you need and can use your keyboard to change the value while it has focus (but not opened). [Here's a lil' screen recording](https://github.com/go-vikunja/frontend/assets/20195269/86e78645-af50-41fe-9ff7-b488ff386c1d). Text inputs seem unaffected at least. Since even the document's root (`<html>`) is being modified, I decided to add a breakpoint on that tag for attribute modifications. It seems a certain attribute is continuously being added and removed, and due to the reactiveness of Vue/Vite it also re-renders a whole bunch of child components every time? First it showed me `<html class="dark" q-has-scope5301926="" lang="en">` and 2 breakpoints later it becomes `<html class="dark" q-has-scope5218981="" lang="en">`. The JS code the debugger is breaking on: ```js var Be = 'q-has-scope' + (Math.floor(9000000 * Math.random()) + 1000000); ze.setAttribute(Be, ''); // Then the breakpoint after that: if (ze.removeAttribute(Be), Ve.length > 0) { ``` As I've mentioned in the starting paragraph: I tried searching for some key parts of this JS in Vue/Vite/Vikunja repos (hoping to find the unobfuscated source) and I couldn't find anything, hence why I'm not sure in what part of the chain this problem exists. I created a [new task on the demo site](https://try.vikunja.io/tasks/43) and I have the same issue there. ### Vikunja Frontend Version 0.22.0 ### Vikunja API Version 0.22.0 ### Browser and version Firefox ESR 115.6.0 ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_
GiteaMirror added the bug label 2026-04-20 16:27:06 -05:00
GiteaMirror commented 2026-04-20 16:27:09 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 10, 2024):

I could not reproduce this in Firefox 121.0, not with the unstable build running on try or locally with a dev build. The tab uses < 0.5% cpu when inactive. Does the task you tested this with have any special attributes?

This sounds like an issue in Vue though. Not sure how to debug this.

<!-- gh-comment-id:1934161453 --> @kolaente commented on GitHub (Jan 10, 2024): I could not reproduce this in Firefox 121.0, not with the unstable build running on try or locally with a dev build. The tab uses < 0.5% cpu when inactive. Does the task you tested this with have any special attributes? This sounds like an issue in Vue though. Not sure how to debug this.
GiteaMirror commented 2026-04-20 16:27:11 -05:00
Author
Owner
Copy Link

@GottemHams commented on GitHub (Jan 10, 2024):

The task doesn't have anything special, literally just creating a new empty task and viewing it is enough.

<!-- gh-comment-id:1934161538 --> @GottemHams commented on GitHub (Jan 10, 2024): The task doesn't have anything special, literally just creating a new empty task and viewing it is enough.
GiteaMirror commented 2026-04-20 16:27:12 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 10, 2024):

Are you able to reproduce this with a newer firefox?

<!-- gh-comment-id:1934161541 --> @kolaente commented on GitHub (Jan 10, 2024): Are you able to reproduce this with a newer firefox?
GiteaMirror commented 2026-04-20 16:27:14 -05:00
Author
Owner
Copy Link

@GottemHams commented on GitHub (Jan 10, 2024):

I'm on the newest version of Firefox's ESR branch. Haven't tried the regular branch though, can maybe do that tomorrow.

<!-- gh-comment-id:1934161550 --> @GottemHams commented on GitHub (Jan 10, 2024): I'm on the newest version of Firefox's ESR branch. Haven't tried the regular branch though, can maybe do that tomorrow.
GiteaMirror commented 2026-04-20 16:27:15 -05:00
Author
Owner
Copy Link

@GottemHams commented on GitHub (Jan 11, 2024):

Alright, so it does seem to work fine on regular Firefox. ESR is officially supported by Mozilla though, and I have my reasons for not using "standard" Firefox in the first place. ;_;

I decided to try removing some elements to see if I could get it to stop re-rendering, then keep going further down the tree to find the actual offending elements. Turns out it's related to Tiptap and/or ProseMirror:

<div class="tiptap ProseMirror" tabindex="0" translate="no" contenteditable="false">
	<p data-placeholder="Enter a description, hit '/' for more options…" class="is-empty is-editor-empty">
		<br class="ProseMirror-trailingBreak">
	</p>
</div>

The editor is being used twice on the task page, once for the task description and another is for adding a new comment. It was literally impossible to remove (or even simply expand) the <p> tag it contains as it seems to be continuously re-added, so it looks like the editor is continuously resetting its innerHTML for whatever reason. I tried entering only 1 character of text in both editors and the re-rendering stops. Both need to have something in them though, so unfortunately it's not as simple as "just enter a task description". The editor being focused (or not) also doesn't matter.

I went looking for some other pages with a rich text editor on them, and I found the project and team edit pages where there's an editor for their descriptions. These have the same issue and the same workaround also works there.

Does this help any? :>

<!-- gh-comment-id:1934161554 --> @GottemHams commented on GitHub (Jan 11, 2024): Alright, so it does seem to work fine on regular Firefox. ESR is officially supported by Mozilla though, and I have my reasons for not using "standard" Firefox in the first place. ;\_; I decided to try removing some elements to see if I could get it to stop re-rendering, then keep going further down the tree to find the actual offending elements. Turns out it's related to Tiptap and/or ProseMirror: ```html <div class="tiptap ProseMirror" tabindex="0" translate="no" contenteditable="false"> <p data-placeholder="Enter a description, hit '/' for more options…" class="is-empty is-editor-empty"> <br class="ProseMirror-trailingBreak"> </p> </div> ``` The editor is being used twice on the task page, once for the task description and another is for adding a new comment. It was literally impossible to remove (or even simply expand) the `<p>` tag it contains as it seems to be continuously re-added, so it looks like the editor is continuously resetting its `innerHTML` for whatever reason. I tried entering **only 1** character of text in both editors and the re-rendering **stops**. Both need to have something in them though, so unfortunately it's not as simple as "just enter a task description". The editor being focused (or not) also doesn't matter. I went looking for some other pages with a rich text editor on them, and I found the project and team edit pages where there's an editor for their descriptions. These have the same issue and the same workaround also works there. Does this help any? :>
GiteaMirror commented 2026-04-20 16:27:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 15, 2024):

This sounds like a bug with the placeholder plugin. I'll take a look.

<!-- gh-comment-id:1934161561 --> @kolaente commented on GitHub (Jan 15, 2024): This sounds like a bug with the placeholder plugin. I'll take a look.
GiteaMirror commented 2026-04-20 16:27:19 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 21, 2024):

Looks like it is not the placeholder. Using git bisect I was able to pin it down to tiptap (the new editor), but it looks like this is not something specific to Vikunja's configuration of it. Given this bug only exists in ESR and there's no obvious fix for this, let's put this on hold until there is a tiptap or Firefox ESR update.

<!-- gh-comment-id:1934161570 --> @kolaente commented on GitHub (Jan 21, 2024): Looks like it is not the placeholder. Using git bisect I was able to pin it down to tiptap (the new editor), but it looks like this is not something specific to Vikunja's configuration of it. Given this bug only exists in ESR and there's no obvious fix for this, let's put this on hold until there is a tiptap or Firefox ESR update.
GiteaMirror commented 2026-04-20 16:27:20 -05:00
Author
Owner
Copy Link

@GottemHams commented on GitHub (Jan 22, 2024):

Alright, just lemme know when you've updated Tiptap in Vikunja and I'll try again.

<!-- gh-comment-id:1934161579 --> @GottemHams commented on GitHub (Jan 22, 2024): Alright, just lemme know when you've updated Tiptap in Vikunja and I'll try again.
GiteaMirror commented 2026-04-20 16:27:21 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 13, 2024):

There have been a few updates to tiptap in the meantime, can you still reproduce this?

<!-- gh-comment-id:2348381446 --> @kolaente commented on GitHub (Sep 13, 2024): There have been a few updates to tiptap in the meantime, can you still reproduce this?
GiteaMirror commented 2026-04-20 16:27:21 -05:00
Author
Owner
Copy Link

@GottemHams commented on GitHub (Sep 16, 2024):

Nope, seems to be good now, it's barely even making a mark on CPU usage. :> For completeness, I'm on Vikunja 0.24.2 but Firefox was still v115.6.0 ESR. After the successful test I decided to also update Firefox (to 115.15.0) and check again. Somehow it still had something cached from the old Vikunja version because the problem re-occurred, but Vikunja also showed the bar at the bottom about an "update" being available. Letting it reload one last time once again fixes the issue, so it was definitely something in Tiptap I'd say.

<!-- gh-comment-id:2353410743 --> @GottemHams commented on GitHub (Sep 16, 2024): Nope, seems to be good now, it's barely even making a mark on CPU usage. :> For completeness, I'm on Vikunja 0.24.2 but Firefox was still v115.6.0 ESR. After the successful test I decided to also update Firefox (to 115.15.0) and check again. Somehow it still had something cached from the old Vikunja version because the problem re-occurred, but Vikunja also showed the bar at the bottom about an "update" being available. Letting it reload one last time once again fixes the issue, so it was definitely something in Tiptap I'd say.
GiteaMirror commented 2026-04-20 16:27:22 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 16, 2024):

Glad it seems to be working now! I'll close this issue then, please ping when you notice the problem again.

<!-- gh-comment-id:2353617618 --> @kolaente commented on GitHub (Sep 16, 2024): Glad it seems to be working now! I'll close this issue then, please ping when you notice the problem again.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#5976
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?