I spent several weeks trying to figure out why images from Windows Snipping Tool could not paste into Quill WYSIWYG and then a couple more weeks trying to fix it and work with other kinds of text and image pastes. I even wrote an issue for it that's still open! I've changed jobs 3 times since I wrote this and now I'm back to using it again in my current work project.
A paste event is detected, but the images never show when you try to copy and paste images from things Windows Snipping Tool. Copying and pasting images from Google, for example, has no issues.
It seems like there is a timing issue for reading files with a base64. I have not been able to reproduce a "fix" I discovered in CodePen, but in the actual project I'm using Quill for, extending the Clipboard module and lengthening the timeout duration at the end of the default onPaste function makes pasting from Snipping Tool work. The bigger the image that needs to be pasted, the larger the duration needs to be.
Again, I am not able to reproduce a bug caused by my "fix", but in my project, lengthening the timeout duration causes two "regular" images to be pasted. I'm throwing this part out there in case it comes up for anyone else. It may be something in my project.
I'm Calin Baenen – AKA KattyTheEnby – a programmer born October 30th, 2006.
I love programming, it has been my passion since I was a kid, and will forever be my passion.
Well, when I was working on the original version of Janky in Python, I was working for god remembers how long trying to figure out how to get properties to work.
And when making RuntDeale prototype in Py, it had a bit of an ordeal with how TKinter wanted to render things.
I spent a week trying to figure out if I was doing something wrong or if I had found a genuine bug in WCF. My gosh it almost broke my spirit. I don't think it has been resolved yet. github.com/microsoft/dotnet/issues...
I was tasked with creating some Ansible configs for these build agents. The machines being spun up from them were identical, but spread across 3 different networks: A, B, and C. The big difference was one zip. A and B got it from shared drives, but C pulled it from our Artifactory. I was told that the one in Artifactory was the same from both A and B.
A and B were fine but machines on C were failing. I figured it was the zip, and it was...but it took the whole day and 2 30-minute Zoom meetings with different folks.
The problem? Well all 3 zips had the same name: Dir_X.Y.Z_14.0 but
The zips on A and B unzipped to C:\Path\To\Dir_X.Y.Z_14.0
The zip on C unzipped to C:\Path\To\Dir_X.Y.Z-14.0
A single-character typo brought me to my knees lol. Someone renamed the directory to have a hyphen, but the zip they created still had an underscore, lol. Ahh good times.
Recently 5 days, off and on between meetings. No stack trace, just a build that kept slowly moving along taking almost 1 hour until I tracked down the culprit: Emotion 10 and how it handles type definitions can slow TypeScript compilation to a crawl. I figured it out by looking for similarities between packages that were slow in a monorepo, then commented out code until I found what caused the slowness and got the build down from 45 minutes to less than 1 minute.
If I ever get to 3 hours staring at the same bug, I generally get up and go for a walk or get some other eyes on it, or try to tackle a different task and come back to the bug later.
Maybe not related, but definitely have had long stretches where a certain bug is 'fixed' only to pop up again a week down the line...
It was about One month. We used a thridparty bpm engine. After a month we identified a memory leak. This Was at least possible with windbg and we identified the memory consume. So we identified that the dispoe doesnt disposed the interna resources...
The most I've worked uninterrupted on the same bug is probably around a week. It was one of the worst bug I'd faced too : Some of our clients data would get randomly deleted for no reason and noone had any idea what was happening. I spent days trying to debug every single API trying to determine what could do that...
I eventually ended up parsing the mysql binlog searching for every delete statement on that table, searching where it came from in our codebase, and rerunning them one by one...
Turns out someone had forgotten some parentheses in an 'OR' condition months before.
~2 months of trying to find a race condition in a bunch of goroutines. I had to create a docker image with the debugging bits included (dlv) to connect to it remotely.
Oldest comments (59)
I spent several weeks trying to figure out why images from Windows Snipping Tool could not paste into Quill WYSIWYG and then a couple more weeks trying to fix it and work with other kinds of text and image pastes. I even wrote an issue for it that's still open! I've changed jobs 3 times since I wrote this and now I'm back to using it again in my current work project.
A paste event is detected, but the images never show when you try to copy and paste images from things Windows Snipping Tool. Copying and pasting images from Google, for example, has no issues.
It seems like there is a timing issue for reading files with a base64. I have not been able to reproduce a "fix" I discovered in CodePen, but in the actual project I'm using Quill for, extending the Clipboard module and lengthening the timeout duration at the end of the default
onPastefunction makes pasting from Snipping Tool work. The bigger the image that needs to be pasted, the larger the duration needs to be.Again, I am not able to reproduce a bug caused by my "fix", but in my project, lengthening the timeout duration causes two "regular" images to be pasted. I'm throwing this part out there in case it comes up for anyone else. It may be something in my project.
Steps for Reproduction
Expected behavior: All image pasting should behave consistently.
Actual behavior: Cannot paste images from snipping tools.
Platforms: Windows 10 (I have not tested this on others yet) Chrome 72
Version: My project uses 1.3.4, but the issue persists in 1.3.6. The CodePen is using 1.3.4.
I've been debugging this PR's formatting bugs and Git errors for around a week 😅
Well, when I was working on the original version of Janky in Python, I was working for god remembers how long trying to figure out how to get properties to work.
And when making RuntDeale prototype in Py, it had a bit of an ordeal with how TKinter wanted to render things.
I spent a week trying to figure out if I was doing something wrong or if I had found a genuine bug in WCF. My gosh it almost broke my spirit. I don't think it has been resolved yet.
github.com/microsoft/dotnet/issues...
Probably a whole 9-hr work day and some change.
I was tasked with creating some Ansible configs for these build agents. The machines being spun up from them were identical, but spread across 3 different networks: A, B, and C. The big difference was one zip. A and B got it from shared drives, but C pulled it from our Artifactory. I was told that the one in Artifactory was the same from both A and B.
A and B were fine but machines on C were failing. I figured it was the zip, and it was...but it took the whole day and 2 30-minute Zoom meetings with different folks.
The problem? Well all 3 zips had the same name: Dir_X.Y.Z_14.0 but
A single-character typo brought me to my knees lol. Someone renamed the directory to have a hyphen, but the zip they created still had an underscore, lol. Ahh good times.
Recently 5 days, off and on between meetings. No stack trace, just a build that kept slowly moving along taking almost 1 hour until I tracked down the culprit: Emotion 10 and how it handles type definitions can slow TypeScript compilation to a crawl. I figured it out by looking for similarities between packages that were slow in a monorepo, then commented out code until I found what caused the slowness and got the build down from 45 minutes to less than 1 minute.
If I ever get to 3 hours staring at the same bug, I generally get up and go for a walk or get some other eyes on it, or try to tackle a different task and come back to the bug later.
Maybe not related, but definitely have had long stretches where a certain bug is 'fixed' only to pop up again a week down the line...
^this
It was about One month. We used a thridparty bpm engine. After a month we identified a memory leak. This Was at least possible with windbg and we identified the memory consume. So we identified that the dispoe doesnt disposed the interna resources...
The most I've worked uninterrupted on the same bug is probably around a week. It was one of the worst bug I'd faced too : Some of our clients data would get randomly deleted for no reason and noone had any idea what was happening. I spent days trying to debug every single API trying to determine what could do that...
I eventually ended up parsing the mysql binlog searching for every delete statement on that table, searching where it came from in our codebase, and rerunning them one by one...
Turns out someone had forgotten some parentheses in an 'OR' condition months before.
~2 months of trying to find a race condition in a bunch of goroutines. I had to create a docker image with the debugging bits included (dlv) to connect to it remotely.