Issue with Version-15 Customize Form, it freeze when saving

Hi friends,

Is anyone else experiencing issues with the Version-15 Customize Form? Whenever I use it to add custom fields or property setters, the form freezes for a long time during the save process. The browser even prompts the “Website Not Responding” dialog several times before the save is successful.

I’ve been a Frappe developer for a long time and have worked with v13, v14, and now v15. This issue only occurs in v15. I’ve tested it across various sites, benches, and servers, and the problem persists everywhere.

Am I missing something in the environment setup, or is this a bug? Any feedback would be appreciated.

P.S. I am using Docker for all my setups, in case that information is helpful.

Version: I’m still experiencing the issue with the latest update v15.39.0
ERPNext: develop branch
Docker image: frappe/bench:latest

HI @jk1117:

Any errors on browser console?

Everything seems fine in both the browser console and bench logs.

However, if you look at the bench logs, you’ll notice that from the moment I opened the Customize Form, made changes, and saved (around 04:34:39), it didn’t finish saving the customization until 04:37:13—about 3 minutes later.

This was a relatively quick case since I only made a small change. If I make multiple customizations, like adding 2 to 3 fields, it usually takes around 10 minutes.


It’s pretty strange … I haven’t seen issues like that.
Get “expected” performance on regular operations with framework?

Tried profiling with Recorder? Maybe some db issue on tables like DocField, Property Setter, etc …

I’m not sure if it’s normal to run this many queries. The two functions with the longest durations are fetch_to_customize and save_customizations. Also, I’m unsure if the duration is measured in seconds or milliseconds—if it’s in seconds, the total process takes about 3 minutes.

Another thing I noticed is that after I click the “Update” button on the UI, it takes about 3 minutes before the save_customizations function actually starts. Could this be a frontend issue, possibly something occurring in the Vue layer? I’m not familiar with the Customize Form implementation.

After some checking, it turns out the issue is indeed on the frontend.
image

The code taking the longest time to run is this line: update_fields_from_form_builder, it took about 2 minutes to run (see the link below):

This confirms it’s a frontend issue. If I’m the only one experiencing this problem, could it be due to having the wrong NodeJS version, VueJS version, or some other frontend misconfiguration? However, I’m using the official Docker image: frappe/bench

btw, my machine have the following specs which is a lot, so I don’t think is machine bottleneck:
Memory: 64GB (docker have access to 30GB of those)
CPU: 6 Cores 12 Threads

First of all, sorry for the frequent updates. I just checked with my colleagues, and they aren’t experiencing this issue. It’s strange because I consistently face this problem on three different laptops and PCs.

I then suspected it might be a browser issue, so I tested it on Microsoft Edge, and it ran normally without any issues. This seems to confirm that the problem is with my Google Chrome browser. I’m currently using the latest version of Chrome: 127.0.6533.120.

I’m not sure what the exact problem is, but I’ll continue investigating. Has anyone else faced this same issue? More information from others might help pinpoint the problem. Any insights would be appreciated!

1 Like

Hi @jk1117:

I see some assets (ace.js) strangely slow access time … tried other browser?

Ok, I see … try to delete cached content on your browser …

Thanks for the help, @avc. I found the issue—it was caused by a Chrome extension called Vue.js devtools: Vue.js devtools on Chrome Web Store.

This is an official tool by the Vue.js team designed to help developers develop and debug Vue.js applications. However, it was causing some overhead for all Vue applications, including Customize Form. After removing the extension from Chrome, Customize Form is running normally now.

1 Like

Thanks for sharing the solution!