### Steps to reproduce

1. Begin of the deletion Install OpenProject 13

2. Create multiple tasks and set estimated time

3. End of the deletion Have Begin of the insertiona workpackageEnd of the insertion Begin of the deletion some tasksEnd of the deletion with Begin of the insertiona large amount ofEnd of the insertion Begin of the deletion 570End of the deletion comments Begin of the insertion(570 is mentioned as an example)End of the insertion

Begin of the insertion2.End of the insertion Begin of the deletion 4.End of the deletion Begin of the insertionAttemptEnd of the insertion Begin of the deletion Set some arbitrary remaining time and a mismatching/unproportional completion percentage

5. UpgradeEnd of the deletion to Begin of the insertionopenEnd of the insertion Begin of the deletion version 14 or higher


Context: We've migrated fromEnd of the deletion the Begin of the insertionworkpackage


End of the insertion Begin of the deletion latest 13.x branch version to latest 14.x, then upgraded PostgreSQL to v17 and moved OpenProject straight to 16.2.2 right after that

End of the deletion ### What is the buggy behavior?

Begin of the deletion <br>

NOTE: This bug causes almost the entirety of old/pre-existing projects and tasks to be unusable, untouchable due to users&#39; browsers hanging and server silently refusing changes/updates

End of the deletion * Begin of the insertionBrowser freezes/becomes unresponsive

End of the insertion Begin of the deletion The migration to v14+&#39;s new time/percentage behaviour is inaccurate and miscalculates percentages

End of the deletion * Begin of the insertionEven if &nbsp;- after a long wait -End of the insertion Begin of the deletion Example: 0.25h estimated, remaining 0.06h

* Percentage should be 76% but ends up as 75% during migration

* ~~OnceEnd of the deletion the Begin of the insertionpage loads, it does not work well. Scrolling breaks andEnd of the insertion Begin of the deletion mismatch exists inEnd of the deletion the Begin of the insertion page feels unresponsive.

* End of the insertion Begin of the deletion newer version, the webinterface seems to &quot;endlessly?&quot; loop recalculation clientside due to the mismatch~~End of the deletion After analysis, it appears the issues comes from the large number of comments on some tasks (570+)

* Browsers slow down and freeze the moment you open the view to a task

* Begin of the insertion_EspeciallyEnd of the insertion Begin of the deletion EspeciallyEnd of the deletion chromium-based browsers are Begin of the insertionaffected_End of the insertion Begin of the deletion affectedEnd of the deletion

* Begin of the insertion_EspeciallyEnd of the insertion Begin of the deletion EspeciallyEnd of the deletion on middle to lower end or older hardware (Intel 3rd/4th gen, faster but still noticable on Begin of the insertion6th)_End of the insertion Begin of the deletion 6th)End of the deletion

* Begin of the insertion_FirefoxEnd of the insertion Begin of the deletion FirefoxEnd of the deletion also slows down but wont freeze as Begin of the insertionextremely_End of the insertion Begin of the deletion extremelyEnd of the deletion

* Begin of the insertion_ProfilersEnd of the insertion Begin of the deletion ProfilersEnd of the deletion pinpoint these to polyfill library and callstacks go to Begin of the insertionmutationobservers/callbacks_End of the insertion Begin of the deletion mutationobservers/callbacksEnd of the deletion

* Begin of the insertion_RemovingEnd of the insertion Begin of the deletion RemovingEnd of the deletion the callbacks through browser-extensions like tampermonkey massively increases web performance, but breaks .. input validation and actually saving changes to Begin of the insertionbackend_

End of the insertion Begin of the deletion backend

End of the deletion * Begin of the insertion_WhenEnd of the insertion Begin of the deletion !!! This may help pinpointing

* WhenEnd of the deletion opening tasks that Begin of the insertionaren&#39;tEnd of the insertion Begin of the deletion arentEnd of the deletion affected- as long as they have a referenced task with that issue, the browser still experiences significant Begin of the insertionslowdown_End of the insertion Begin of the deletion slowdownEnd of the deletion

* Begin of the insertion_CreatingEnd of the insertion Begin of the deletion CreatingEnd of the deletion new tasks and viewing or editing these works fine without performance Begin of the insertionimpact_


End of the insertion Begin of the deletion impact

* Tring to update such tasks, like start/end-date etc have a silent 422 error, so pressing on save ends up doing nothing

* Only once you open the estimated/remaining-time and percentage popups, it will show you (in red, on % completed), that the number is mismatching the time values

* This seems... pointless? Given v14&#39;s changelog stated that this value is system calculated, not user input, so why validate?

* \=&gt; this issue on progress values has been extracted in <mention class="mention" data-id="66592" data-type="work_package" data-text="##66592">##66592</mention>&nbsp;


\*\*WORKAROUND (\*\*Works, but hacky): Manual DBupdate using this query: 

* update work\_packages set done\_ratio = ((estimated\_hours-remaining\_hours)/estimated\_hours\*100) where estimated\_hours IS NOT NULL and estimated\_hours != 0;

* \=&gt; this fixes the unability to save work packages, but does not fix the performance issue


End of the deletion ### What is the expected behavior?

1. Begin of the insertionWorkpackages with large amount of comments don&#39;t experience performance issues.End of the insertion Begin of the deletion Openproject auto-corrects the percentage on load (serverside)

2. WebInterface wont hangEnd of the deletion


### Begin of the insertion

End of the insertion Begin of the deletion **Logs**

_There are no logs in the browser nor backend on this._
_However, looking at browsers&#39; inbuilt profilers, the issues track down to &quot;extremely long css animations&quot; and 10s+ of javascript cputime (polyfill) most likely due to looping mutation observers/callbacks caused by validation failures (clientside)_

End of the deletion ### Begin of the insertion

End of the insertion Begin of the deletion Screenshots and other files

Example error. Context: manually removing the 75% will make it auto-fill back to 75%, setting remaining time to 0 or setting the percentage to 76% fixes the current task/package.
Once the bug has been fixed, the browser will auto-complete the % to the correct 76% instead if one attempts to blank the field.

<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/769615/content">

\=&gt; this issue on progress values has been extracted in <mention class="mention" data-id="66592" data-type="work_package" data-text="##66592">##66592</mention> 

End of the deletion ### Environment information

**OpenProject installation type**

* Selfhosted, Packaged installation

* Ubuntu 20.04.6 LTS


**OpenProject version**

_16.2.2_

**Browser**

* [x] Chrome
* [x] Firefox
* [ ] Safari
* [ ] Mobile Safari
* [ ] Other (please specify)

**Operating System**

* [x] Windows
* [ ] Mac OS X
* [ ] Mobile iOS
* [ ] Mobile Android
* [ ] Linux (please specify distro)
* [ ] Chrome OS
* [ ] Other (please specify)

**Language**

_English and German_