Bug 504814

Summary: Click and drag with text tools returns an empty vector layer if the active color is not dark enough (nightly build e528a61e)
Product: [Applications] krita Reporter: Regis <regis>
Component: Tool/TextAssignee: Krita Bugs <krita-bugs-null>
Status: REPORTED ---    
Severity: normal CC: griffinvalley
Priority: NOR    
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Regis 2025-05-26 13:14:04 UTC
When using click and drag with the text tool (to set paragraph width), the vector layers ends up empty if the color is not dark enough. It happens since a few versions of the nightly builds (maybe since a few weeks). It doesn't happen when simply clicking on the layer with the text tool.

Steps to reproduce:
1. Open or create a document.
2. Set the active color to a light value.
3. Select the text tool
4. Click and drag to create a paragraph with specific width.

The vector layer created by the text tool will be empty, while in fact it should contain the paragraph (at the right width) with "Placeholder text" as text content.

And if you create a paragraph with dark text this way (by click and drag), it will work, but if you want to change the color of the text to a lighter value afterwards, the program will hang (not necessarily crash).

If I try to create a paragraph with light color, resulting in an empty layer, but I immediately try to change the color to a darker tone, I get this error popup:

"Krita has encountered an internal error:

SAFE ASSERT (krita): "!m_sanityIsStarting" in file C:/builds/graphics/krita/libs/global/kis_signal_compressor.cpp, line 210

Please report a bug to developers!

Press Ignore to try to continue.
Press Abort to see developers information (all unsaved data will be lost)"

For color selection i use the triangle Advanced Color Selector in HSV mode. Any color picked in the top part of the triangle will be OK If I stick to the extreme bottom side of the triangle (really on the border, from pure white to pure saturation), it works too. But all the rest of the color selector surface will generate the bug.

Krita

 Version: 5.3.0-prealpha (git e528a61)
 Installation type: portable package
 Hidpi: true

Qt

  Version (compiled): 5.15.7
  Version (loaded): 5.15.7

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.26100
  Pretty Productname: Windows 10 Version 2009
  Product Type: windows
  Product Version: 10
  Result of IsWindows10OrGreater(): No
Comment 1 wolthera 2025-05-26 13:41:32 UTC
Hi,

I can't reproduce this. Can you give me more information?

1. Which colors cause this? I have personally tried with "#99efe5", "#f4dad0" and "#d7d7d7", none of them seem to cause a crash.
2. Which font are you trying this with? Does it happen with all fonts?
Comment 2 Regis 2025-05-26 14:35:13 UTC
I tried the colors you mentioned (#99efe5, #f4dad0, #d7d7d7) and it caused the same issue.
I just noticed it doesn't affect all color hues in the same manner on my side either. For example for greens, the "zone" on the color selector creating the bug is fairly smaller, but still it's there.
But shades of red are especially affected on my side. For example this one: #bf3429.

The font is Segoe UI (default on Windows I think). I switch to Verdana and it doesn't change a thing.

I'll try a total reset of my settings by moving temporarily my resources folder to see if it helps.
Comment 3 Regis 2025-05-26 14:39:38 UTC
Update: I reset both my resources folder and the settings via the interface (Settings -> reset all settings) and the issue is still here for me.
Comment 4 Regis 2025-05-26 21:04:47 UTC
So far I had the issue on two Windows computers (one on Windows 11 Home, the other on Windows 11 Pro). A total reset of Krita didn't help.
I tested the same build on my Linux install (Mint Cinnamon), and no problem here. So it might be a Windows related issue.
Tomorrow, I'll try to get my hand on the last nightly that didn't have the problem on Windows, if that can help find out what changed when it started to happen.
Comment 5 Bug Janitor Service 2025-05-27 03:47:36 UTC
๐Ÿ›๐Ÿงน Thanks for your comment!

Automatically switching the status to REPORTED so the team can perform further triage.

In the future you may also do this yourself when providing needed information.
Comment 6 Regis 2025-06-12 10:34:00 UTC
Hi,

I managed to test the nightly build on another Windows 11 computer (version 24H2) where there was no version of Krita installed before, and with only default settings. It seemed to work better, I could create text by click and drag with most of the colors that caused issues on my computer.

But still, I could reproduce the bug with some colors, one of them being this one: #8fdf9b
I created a block by click and drag with this color and the block appeared empty. If I create a block the same way but with another color that works, and then select the text and change the color to #8fdf9b, the text disappears, or worse, Krita hangs and crashes after a few seconds or minutes.

I hope this helps reproduce the issue!