Copy/Paste one single field (text type) to another one gets my PC to a hang on status

I have a problem with copy/paste. If I do multiple fields from one column, there is no problem, but if I copy just one, then my computer hangs on. I have to wait and then kill the browser process.
Just to mention that I am talking about coying just simple “Long text” field type and there is only a few words in it. So nothing complicated.
My table has some 2300 rows and consists of about 34 columns of different types (Text, Calendar, multiple select, Linked to table etc. etc.).

Hi @marcus some questions to help us track down the problem:

Are you using or a self hosted instance? If so what version of Baserow are you self hosting?

What browser and broswer extensions are you using?

Does the problem still occur when you change browsers?

Does the problem still occur when you switch to private/incognito mode?

Yes, my baserow is running as an container in Docker in my Synology NAS (DS1618+ intel-based x86_64, 32 GB of RAM, quad core, NVMe SSD cache - I believe there is no problem with the performance here).

I tried Firefox, Chrome, Edge (in my Edge browser I have no extension installed). I even tried three different computers (one was Win 10 Pro, another one Win 11 Pro, third one Win 7 Pro). There is no problem of hardware performance (teh Win 10 Pro PC has 64 GB of RAM, Core i9 and powerfull NVIDIA RTX 3090 graphic card - 3D acceleration is turned on in the browser settings).

I tried incognito (private) window in Firefox as well as in Edge, but still the same problem.

To describe the problem as best as I can: if I click (i mean select) the cell (text type) and make a copy (CTRL+C), then the whole system (so not only the browser) is almost without response. What I am able to do is to open the Task Manager and kill the browser process. Then my system is back to life. BUT if I do a click-through into the cell (so it is framed by that blue frame) and select+copy the text, there is no problem.

The strange thing is that if I click/select more than just one cell (two, thre, four, seven, …) and do a copy, then it’s working without any issue as well…

Btw. if my system ghands on due to this issue, it’s not about that its resources are overloaded. No, the CPU as well as RAM still have normal (low %) values - as far as I can say by inspecting in Task Manager’s Performance section. And tasks (applications) consume just normal amount of resources too.

And which version of Baserow are you using? We fixed exactly this bug maybe a couple of versions ago.

One hour ago I just updated to the latest one and tried. But no change unfortunately.

(Btw. where can I find the baserow version than I am running? Somewhere in dashboard?)

You can check what Baserow version you’re currently running by opening the API spec docs: Baserow API spec.

Thanks, I found it. So my version is the most recent 1.17


Is the dev team able to simulate the similar environment and reproduce that “copy cell” bug I’ve described above? Baserow is great product and I am a fan of it, but if declaring that it is blazing fast even witch hundreds of thousand rows in the table … and one simple click/copy the cell can compleetely freeze not onlt baserow but the whole system. This is really weird. :frowning:

Could you also let me know which specific Baserow image you’ve deployed (the baserow/baserow:1.17.0 one i’m guessing?
Otherwise thanks for all the detailed information i’ll dig into this further. This is unfortunately a rare bug that we’ve never been able to reproduce and was reported as fixed a few months ago.

Would you be open for deploying a debug build of Baserow with some enhanced logging to help me track down the issue if i’m not able to reproduce this time also?

Hi, I am using baserow/baserow:latest image (downloaded directly via Portainer), ID number is 623bb7b0f437ce09036d715a0a12827fb67103e0a790cbae9c86f09032d327bd

Hopefully, this can help you.

And sure, I am opened to any help you can provide, including enhanced logging so you could have more chances to track the bug. Just let me know, if it would have some impact to my database in terms of not being able to work with it during some time. There are two or three people who are working with it daily so I would have first to manage some time slot and communicate to them that baserow will be unaccessible for some time.
I suppose and require that no data or database integrity or configuration will be lost. Can you confirm this?

Hi, any news or instructions s in relation to the problem described above?

Not yet sorry, it’s on our todo list to investigate as we are spending this week squashing bugs etc.

OK, no problem. Just let me know any time later.

It sounds very similar to this: Hard freeze on chrome when copying field - gridField.copyEventListener recursively calls itself (see stack trace from developer tools)

So is that freezing bug solved? If yes, then what needs to be done at the user’s side?

not solved, as of baserow 1.17.2 i’m still experiencing this. @marcus are you accessing your baserow instance over http or https ?

I am accessing it over http, just only on my local LAN, using an internal IP address and port (as configured in a Docker).
Btw. what’s improved or changed in this small 1.17.2 update, comparing to a previous one. Is there any Release notes page?

Sure, you can find the changelog here: · develop · Baserow / baserow · GitLab.

1 Like

@marcus OK, I think it’s the same bug. The copy code has 2 branches, one which is used when accessing over https, one which is used when accessed over http. The one for http has the freezing bug. Hard freeze on chrome when copying field - gridField.copyEventListener recursively calls itself