Bug 443111

Summary: Create from Clipboard not working as intended
Product: [Applications] krita Reporter: Rexel <rexel325>
Component: File formatsAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: crash CC: ahab.greybeard, dimula73, halla, tamtamy.tymona, tomtomtomreportingin
Priority: NOR Keywords: regression, release_blocker
Version: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Other   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Rexel 2021-09-29 10:46:39 UTC
SUMMARY
Create from Clipboard is a bit buggy in Krita 5. I've tested it in both beta1 and pre-alpha and got the same results.

STEPS TO REPRODUCE
1. Right click an image from a browser
2. Select copy image
3. Click New File in Krita
4. Click Create from Clipboard

OBSERVED RESULT

I've gotten a few different results:

a. Krita crashes
b. Krita doesn't detect the new image and image dimensions from the clipboard
c. Krita creates an image but only gets the correct dimensions with a white background layer, the image from the clipboard has to be pasted manually.
d. Krita doesn't show the preview of the image from the clipboard in the Create New Document docker

EXPECTED RESULT

Krita shows a preview of the image from the clipboard, and clicking Create would automatically put the image from the clipboard as the background layer in the new document as it has done in Krita 4

SOFTWARE/OS VERSIONS
Krita

 Version: 5.1.0-prealpha (git ab9b478)
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.11
  Version (loaded): 5.12.11

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.19042
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
 
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (NVIDIA GeForce RTX 2060 Direct3D11 vs_5_0 ps_5_0)" 
  Version:  "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" 
  Shading language:  "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:    QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
     Version: 3.0
     Supports deprecated functions false 
     is OpenGL ES: true 
  supportsBufferMapping: true 
  supportsBufferInvalidation: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: true 

useBufferInvalidation (config option): false


Hardware Information

  GPU Acceleration: auto
  Memory: 16332 Mb
  Number of Cores: 12
  Swap Location: C:/Users/Rexel Bartolome/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/Rexel Bartolome/AppData/Local/Temp
  Current Swap Location writable: true
  Undo Enabled: true
  Undo Stack Limit: 30
  Use OpenGL: true
  Use OpenGL Texture Buffer: true
  Disable Vector Optimizations: false
  Disable AVX Optimizations: false
  Canvas State: OPENGL_SUCCESS
  Autosave Interval: 900
  Use Backup Files: true
  Number of Backups Kept: 1
  Backup File Suffix: ~
  Backup Location: Same Folder as the File
  Backup Location writable: false
  Use Win8 Pointer Input: true
  Use RightMiddleTabletButton Workaround: false
  Levels of Detail Enabled: false
  Use Zip64: false


Display Information
Number of screens: 2
	Screen: 0
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
	Screen: 1
		Name: \\.\DISPLAY2
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
Comment 1 Halla Rempt 2021-09-29 10:57:06 UTC
Which browser are you using? There is a known bug in Chrome that puts images on the clipboard in a broken way...
Comment 2 Rexel 2021-09-29 11:14:47 UTC
(In reply to Halla Rempt from comment #1)
> Which browser are you using? There is a known bug in Chrome that puts images
> on the clipboard in a broken way...

I'm using Firefox, and actually now that I've tested it, everything works fine when I copy images from Chrome but not Firefox :(

I'm also using the portable zip versions of Krita 5 as I want to keep Krita 4 as my main workhorse while I test things out.

I've tested it again on Krita 4 and copying from both Firefox and Chrome works fine.
Comment 3 Halla Rempt 2021-09-29 11:28:55 UTC
I can also reproduce this with firefox _and_ chromeium on Linux.
Comment 4 tomtomtomreportingin 2021-10-01 00:05:42 UTC
I don't think this is browser-related as I've come across this issue with images copied from Krita itself.

1. Create an A5 600 DPI document with layers.
2. On Paint Layer 1, create a max setting Random Noise filter mask.
3. Flatten the image and cut with Ctrl + X.
4. Check Create from Clipboard, it should be read properly at this moment.
4. Restart Krita.
5. Check Create from Clipboard, it's no longer read properly. Sometimes you'll get an image with wrong dimensions or the image won't be read at all.
Comment 5 Dmitry Kazakov 2021-10-05 05:24:53 UTC
Git commit afb8e54832f8ffd59d0272183ecc537a0aca06a3 by Dmitry Kazakov.
Committed on 05/10/2021 at 05:24.
Pushed by dkazakov into branch 'master'.

Fix assert when creating an image from Krita's internal clipboard

When we copy local nodes, we should reinitialize both image and
shape controller links. This patch fixes the former link, but keeps
the second one unset.

It should fix a crash when creating an image from the clipboard.

M  +7    -1    libs/ui/kis_mimedata.cpp

https://invent.kde.org/graphics/krita/commit/afb8e54832f8ffd59d0272183ecc537a0aca06a3
Comment 6 Ahab Greybeard 2021-10-08 16:31:55 UTC
The Oct 07 5.1.0-prealpha (git f2ad3000) appimage on Debian 10 MATE still has a strange problem.

When first started, an image copied using the 'Eye of MATE' image viewer will cause a crash if I use Edit -> Paste into New Image.

An image copied with the 'gThumb' image viewer will have no problems after usaing Edit -> Paste into New Image.
After that, I can use an image copied with 'Eye of MATE' with Edit -> Paste into New Image and krita will then give me the list of options of how to paste it.
Choosing to paste into a new document gives no problems.

When it crashes, the terminal says "Segmentation fault". There is no relevant log entry.
Comment 7 Dmitry Kazakov 2021-10-12 06:09:59 UTC
I can confirm the crash :(
Comment 8 Dmitry Kazakov 2021-10-12 08:43:00 UTC
Git commit 8f6c508e889c694876d806750489d5c6e00b1fb0 by Dmitry Kazakov.
Committed on 12/10/2021 at 08:42.
Pushed by dkazakov into branch 'master'.

Fix crash when creating a new image with URL present in the clipboard

Basically,  KisClipboard::clip() should not ask anything related to
multiple URLs in the clipboard. Its responsibility to load only one
image from the clipboard (the first URL if there are multiple).

Parsing of multiple URLs is the responsibility of a higher level code.

M  +9    -2    libs/ui/actions/KisPasteActionFactories.cpp
M  +2    -7    libs/ui/kis_clipboard.cc
M  +49   -0    libs/ui/utils/KisClipboardUtil.cpp
M  +3    -0    libs/ui/utils/KisClipboardUtil.h

https://invent.kde.org/graphics/krita/commit/8f6c508e889c694876d806750489d5c6e00b1fb0
Comment 9 Dmitry Kazakov 2021-10-12 10:01:59 UTC
The bug seems to be fixed now. I have tested the following cases:

1) "Copy Buffer" from nomacs works
2) "Copy" (file url) from nomacs works
3) "Copy Image" works on both Firefox and Chromium
4) "Copy Link" doesn't work, neither on Firefox nor on Chromium, because they save the link as text/plain.

For every case I tried the following:

a) Create new document from clipboard
b) Ctrl+V the clip into existing document

If you still have issues, please reopen the bug :)
Comment 10 Dmitry Kazakov 2021-10-13 08:19:08 UTC
Git commit df528d74058bc976a103d4f10e2a53d960a054c2 by Dmitry Kazakov.
Committed on 13/10/2021 at 08:18.
Pushed by dkazakov into branch 'krita/5.0'.

Fix crash when creating a new image with URL present in the clipboard

Basically,  KisClipboard::clip() should not ask anything related to
multiple URLs in the clipboard. Its responsibility to load only one
image from the clipboard (the first URL if there are multiple).

Parsing of multiple URLs is the responsibility of a higher level code.

M  +10   -2    libs/ui/actions/KisPasteActionFactories.cpp
M  +2    -7    libs/ui/kis_clipboard.cc
M  +49   -0    libs/ui/utils/KisClipboardUtil.cpp
M  +3    -0    libs/ui/utils/KisClipboardUtil.h

https://invent.kde.org/graphics/krita/commit/df528d74058bc976a103d4f10e2a53d960a054c2
Comment 11 Tiar 2021-10-21 14:45:09 UTC
*** Bug 443902 has been marked as a duplicate of this bug. ***
Comment 12 Dmitry Kazakov 2021-11-17 14:01:01 UTC
Git commit 510842271ecd1b6f56163636235d5642ba7b16e2 by Dmitry Kazakov.
Committed on 17/11/2021 at 13:47.
Pushed by dkazakov into branch 'krita/5.0'.

Fix assert when creating an image from Krita's internal clipboard

When we copy local nodes, we should reinitialize both image and
shape controller links. This patch fixes the former link, but keeps
the second one unset.

It should fix a crash when creating an image from the clipboard.

M  +7    -1    libs/ui/kis_mimedata.cpp

https://invent.kde.org/graphics/krita/commit/510842271ecd1b6f56163636235d5642ba7b16e2
Comment 13 amyspark 2021-11-27 13:21:58 UTC
Git commit 30f7b1c9e966dca97f83f24da077df2789168aa8 by L. E. Segovia.
Committed on 27/11/2021 at 00:43.
Pushed by lsegovia into branch 'krita/5.0'.

Fix position inconsistency in Paste at Cursor

URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction,
which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip
also handles URL-backed images via KisClipboardUtil::fetchImageByURL.
Conversely, clipboard bitmaps are pasted into a paint device which is
then recentered.
This commit fixes the dissonance by dropping the specialization, and
ensuring that all clip() paths are centered.
Related: bug 446120

M  +0    -6    libs/ui/actions/KisPasteActionFactories.cpp
M  +7    -5    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/30f7b1c9e966dca97f83f24da077df2789168aa8
Comment 14 amyspark 2021-11-27 13:25:56 UTC
Git commit 573a7622a2fbddef8379c2b84fe6eadfd24a46e6 by L. E. Segovia.
Committed on 27/11/2021 at 13:25.
Pushed by lsegovia into branch 'master'.

Fix position inconsistency in Paste at Cursor

URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction,
which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip
also handles URL-backed images via KisClipboardUtil::fetchImageByURL.
Conversely, clipboard bitmaps are pasted into a paint device which is
then recentered.
This commit fixes the dissonance by dropping the specialization, and
ensuring that all clip() paths are centered.
Related: bug 446120
(cherry picked from commit 30f7b1c9e966dca97f83f24da077df2789168aa8)

M  +0    -6    libs/ui/actions/KisPasteActionFactories.cpp
M  +7    -5    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/573a7622a2fbddef8379c2b84fe6eadfd24a46e6